<?xml version="1.0" encoding="UTF-8"?>
<updates>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-BA-2025-1029</id>
          <title>An update for iproute is now available for openEuler-22.03-LTS-SP4</title>
          <severity></severity>
          <release>openEuler</release>
          <issued date="2025-04-25"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/BUG-2025-IBV9EQ" id="BUG-2025-IBV9EQ" title="BUG-2025-IBV9EQ" type="cve"></reference>
          </references>
          <description>修复了iproute中iplink模块在处理网络命名空间时的文件描述符泄露问题(BUG-2025-IBV9EQ)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="iproute" release="24.oe2203sp4" version="5.15.0">
                         <filename>iproute-5.15.0-24.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="iproute-debuginfo" release="24.oe2203sp4" version="5.15.0">
                         <filename>iproute-debuginfo-5.15.0-24.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="iproute-debugsource" release="24.oe2203sp4" version="5.15.0">
                         <filename>iproute-debugsource-5.15.0-24.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="iproute-devel" release="24.oe2203sp4" version="5.15.0">
                         <filename>iproute-devel-5.15.0-24.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="iproute-help" release="24.oe2203sp4" version="5.15.0">
                         <filename>iproute-help-5.15.0-24.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="iproute" release="24.oe2203sp4" version="5.15.0">
                         <filename>iproute-5.15.0-24.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="iproute-debuginfo" release="24.oe2203sp4" version="5.15.0">
                         <filename>iproute-debuginfo-5.15.0-24.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="iproute-debugsource" release="24.oe2203sp4" version="5.15.0">
                         <filename>iproute-debugsource-5.15.0-24.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="iproute-devel" release="24.oe2203sp4" version="5.15.0">
                         <filename>iproute-devel-5.15.0-24.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-BA-2025-1036</id>
          <title>An update for chrony is now available for openEuler-22.03-LTS-SP4</title>
          <severity></severity>
          <release>openEuler</release>
          <issued date="2025-04-25"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/BUG-2025-IBVRW2" id="BUG-2025-IBVRW2" title="BUG-2025-IBVRW2" type="cve"></reference>
          </references>
          <description>修复了chronyd启动时，在初始化步骤和RTC初始化期间接收重新加载源命令导致的崩溃问题。通过在正常运行模式前忽略重新加载命令来实现修复(BUG-2025-IBVRW2)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="chrony" release="7.oe2203sp4" version="4.1">
                         <filename>chrony-4.1-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="chrony-debuginfo" release="7.oe2203sp4" version="4.1">
                         <filename>chrony-debuginfo-4.1-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="chrony-debugsource" release="7.oe2203sp4" version="4.1">
                         <filename>chrony-debugsource-4.1-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="chrony-help" release="7.oe2203sp4" version="4.1">
                         <filename>chrony-help-4.1-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="chrony" release="7.oe2203sp4" version="4.1">
                         <filename>chrony-4.1-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="chrony-debuginfo" release="7.oe2203sp4" version="4.1">
                         <filename>chrony-debuginfo-4.1-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="chrony-debugsource" release="7.oe2203sp4" version="4.1">
                         <filename>chrony-debugsource-4.1-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-BA-2025-1040</id>
          <title>An update for bind is now available for openEuler-22.03-LTS-SP4</title>
          <severity></severity>
          <release>openEuler</release>
          <issued date="2025-05-23"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/BUG-2025-IC8P0L" id="BUG-2025-IC8P0L" title="BUG-2025-IC8P0L" type="cve"></reference>
          </references>
          <description>bind-dyndb-ldap编译失败(BUG-2025-IC8P0L)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="32" arch="aarch64" name="bind" release="26.oe2203sp4" version="9.16.23">
                         <filename>bind-9.16.23-26.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-chroot" release="26.oe2203sp4" version="9.16.23">
                         <filename>bind-chroot-9.16.23-26.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-debuginfo" release="26.oe2203sp4" version="9.16.23">
                         <filename>bind-debuginfo-9.16.23-26.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-debugsource" release="26.oe2203sp4" version="9.16.23">
                         <filename>bind-debugsource-9.16.23-26.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-devel" release="26.oe2203sp4" version="9.16.23">
                         <filename>bind-devel-9.16.23-26.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-dnssec-utils" release="26.oe2203sp4" version="9.16.23">
                         <filename>bind-dnssec-utils-9.16.23-26.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-libs" release="26.oe2203sp4" version="9.16.23">
                         <filename>bind-libs-9.16.23-26.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-pkcs11" release="26.oe2203sp4" version="9.16.23">
                         <filename>bind-pkcs11-9.16.23-26.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-pkcs11-devel" release="26.oe2203sp4" version="9.16.23">
                         <filename>bind-pkcs11-devel-9.16.23-26.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-pkcs11-libs" release="26.oe2203sp4" version="9.16.23">
                         <filename>bind-pkcs11-libs-9.16.23-26.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-pkcs11-utils" release="26.oe2203sp4" version="9.16.23">
                         <filename>bind-pkcs11-utils-9.16.23-26.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-utils" release="26.oe2203sp4" version="9.16.23">
                         <filename>bind-utils-9.16.23-26.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="noarch" name="bind-dnssec-doc" release="26.oe2203sp4" version="9.16.23">
                         <filename>bind-dnssec-doc-9.16.23-26.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="32" arch="noarch" name="bind-license" release="26.oe2203sp4" version="9.16.23">
                         <filename>bind-license-9.16.23-26.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="32" arch="noarch" name="python3-bind" release="26.oe2203sp4" version="9.16.23">
                         <filename>python3-bind-9.16.23-26.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind" release="26.oe2203sp4" version="9.16.23">
                         <filename>bind-9.16.23-26.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-chroot" release="26.oe2203sp4" version="9.16.23">
                         <filename>bind-chroot-9.16.23-26.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-debuginfo" release="26.oe2203sp4" version="9.16.23">
                         <filename>bind-debuginfo-9.16.23-26.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-debugsource" release="26.oe2203sp4" version="9.16.23">
                         <filename>bind-debugsource-9.16.23-26.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-devel" release="26.oe2203sp4" version="9.16.23">
                         <filename>bind-devel-9.16.23-26.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-dnssec-utils" release="26.oe2203sp4" version="9.16.23">
                         <filename>bind-dnssec-utils-9.16.23-26.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-libs" release="26.oe2203sp4" version="9.16.23">
                         <filename>bind-libs-9.16.23-26.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-pkcs11" release="26.oe2203sp4" version="9.16.23">
                         <filename>bind-pkcs11-9.16.23-26.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-pkcs11-devel" release="26.oe2203sp4" version="9.16.23">
                         <filename>bind-pkcs11-devel-9.16.23-26.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-pkcs11-libs" release="26.oe2203sp4" version="9.16.23">
                         <filename>bind-pkcs11-libs-9.16.23-26.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-pkcs11-utils" release="26.oe2203sp4" version="9.16.23">
                         <filename>bind-pkcs11-utils-9.16.23-26.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-utils" release="26.oe2203sp4" version="9.16.23">
                         <filename>bind-utils-9.16.23-26.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-BA-2025-1045</id>
          <title>An update for kmod-kvdo is now available for openEuler-22.03-LTS-SP4</title>
          <severity></severity>
          <release>openEuler</release>
          <issued date="2025-05-30"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/BUG-2025-IC9FCX" id="BUG-2025-IC9FCX" title="BUG-2025-IC9FCX" type="cve"></reference>
          </references>
          <description>版本变更导致的依赖缺失(BUG-2025-IC9FCX)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kmod-kvdo" release="3.oe2203sp4" version="8.1.0.316">
                         <filename>kmod-kvdo-8.1.0.316-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kmod-kvdo" release="3.oe2203sp4" version="8.1.0.316">
                         <filename>kmod-kvdo-8.1.0.316-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-BA-2025-1050</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2025-05-30"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/BUG-2025-IC88AI" id="BUG-2025-IC88AI" title="BUG-2025-IC88AI" type="cve"></reference>
          </references>
          <description>带业务拔盘，可能会引发群体慢盘。(BUG-2025-IC88AI)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="bpftool" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-265.0.0.168.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-265.0.0.168.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-265.0.0.168.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-265.0.0.168.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-265.0.0.168.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-265.0.0.168.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-265.0.0.168.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-265.0.0.168.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-265.0.0.168.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-265.0.0.168.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-265.0.0.168.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-265.0.0.168.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-265.0.0.168.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-265.0.0.168.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-265.0.0.168.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-265.0.0.168.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-265.0.0.168.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-265.0.0.168.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-265.0.0.168.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-265.0.0.168.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-265.0.0.168.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-265.0.0.168.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-265.0.0.168.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-265.0.0.168.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-265.0.0.168.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-265.0.0.168.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-265.0.0.168.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-265.0.0.168.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-265.0.0.168.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-265.0.0.168.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-BA-2025-1056</id>
          <title>An update for procps-ng is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2025-06-20"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/BUG-2025-ICCHNW" id="BUG-2025-ICCHNW" title="BUG-2025-ICCHNW" type="cve"></reference>
          </references>
          <description>获取不到ID_RUSER字段的异常场景会触发此问题，概率极低，修复前版本6w次暂未复现(BUG-2025-ICCHNW)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="procps-ng" release="15.oe2203sp4" version="4.0.2">
                         <filename>procps-ng-4.0.2-15.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="procps-ng-debuginfo" release="15.oe2203sp4" version="4.0.2">
                         <filename>procps-ng-debuginfo-4.0.2-15.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="procps-ng-debugsource" release="15.oe2203sp4" version="4.0.2">
                         <filename>procps-ng-debugsource-4.0.2-15.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="procps-ng-devel" release="15.oe2203sp4" version="4.0.2">
                         <filename>procps-ng-devel-4.0.2-15.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="procps-ng-help" release="15.oe2203sp4" version="4.0.2">
                         <filename>procps-ng-help-4.0.2-15.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="procps-ng-i18n" release="15.oe2203sp4" version="4.0.2">
                         <filename>procps-ng-i18n-4.0.2-15.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="procps-ng" release="15.oe2203sp4" version="4.0.2">
                         <filename>procps-ng-4.0.2-15.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="procps-ng-debuginfo" release="15.oe2203sp4" version="4.0.2">
                         <filename>procps-ng-debuginfo-4.0.2-15.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="procps-ng-debugsource" release="15.oe2203sp4" version="4.0.2">
                         <filename>procps-ng-debugsource-4.0.2-15.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="procps-ng-devel" release="15.oe2203sp4" version="4.0.2">
                         <filename>procps-ng-devel-4.0.2-15.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1782</id>
          <title>An update for openssh is now available for openEuler-22.03-LTS-SP4</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.oe2203sp4" version="8.8p1">
                         <filename>openssh-8.8p1-31.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-askpass" release="31.oe2203sp4" version="8.8p1">
                         <filename>openssh-askpass-8.8p1-31.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-clients" release="31.oe2203sp4" version="8.8p1">
                         <filename>openssh-clients-8.8p1-31.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-debuginfo" release="31.oe2203sp4" version="8.8p1">
                         <filename>openssh-debuginfo-8.8p1-31.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-debugsource" release="31.oe2203sp4" version="8.8p1">
                         <filename>openssh-debugsource-8.8p1-31.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-keycat" release="31.oe2203sp4" version="8.8p1">
                         <filename>openssh-keycat-8.8p1-31.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-server" release="31.oe2203sp4" version="8.8p1">
                         <filename>openssh-server-8.8p1-31.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pam_ssh_agent_auth" release="4.31.oe2203sp4" version="0.10.4">
                         <filename>pam_ssh_agent_auth-0.10.4-4.31.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="openssh-help" release="31.oe2203sp4" version="8.8p1">
                         <filename>openssh-help-8.8p1-31.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh" release="31.oe2203sp4" version="8.8p1">
                         <filename>openssh-8.8p1-31.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-askpass" release="31.oe2203sp4" version="8.8p1">
                         <filename>openssh-askpass-8.8p1-31.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-clients" release="31.oe2203sp4" version="8.8p1">
                         <filename>openssh-clients-8.8p1-31.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-debuginfo" release="31.oe2203sp4" version="8.8p1">
                         <filename>openssh-debuginfo-8.8p1-31.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-debugsource" release="31.oe2203sp4" version="8.8p1">
                         <filename>openssh-debugsource-8.8p1-31.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-keycat" release="31.oe2203sp4" version="8.8p1">
                         <filename>openssh-keycat-8.8p1-31.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-server" release="31.oe2203sp4" version="8.8p1">
                         <filename>openssh-server-8.8p1-31.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pam_ssh_agent_auth" release="4.31.oe2203sp4" version="0.10.4">
                         <filename>pam_ssh_agent_auth-0.10.4-4.31.oe2203sp4.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-SP4</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 epoch="7" arch="aarch64" name="squid" release="25.oe2203sp4" version="4.9">
                         <filename>squid-4.9-25.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="squid-debuginfo" release="25.oe2203sp4" version="4.9">
                         <filename>squid-debuginfo-4.9-25.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="squid-debugsource" release="25.oe2203sp4" version="4.9">
                         <filename>squid-debugsource-4.9-25.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="squid" release="25.oe2203sp4" version="4.9">
                         <filename>squid-4.9-25.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="squid-debuginfo" release="25.oe2203sp4" version="4.9">
                         <filename>squid-debuginfo-4.9-25.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="squid-debugsource" release="25.oe2203sp4" version="4.9">
                         <filename>squid-debugsource-4.9-25.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1795</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-07-05"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27405" id="CVE-2024-27405" title="CVE-2024-27405" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35899" id="CVE-2024-35899" title="CVE-2024-35899" 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-38556" id="CVE-2024-38556" title="CVE-2024-38556" 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-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>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:usb: gadget: ncm: Avoid dropping datagrams of properly parsed NTBsIt is observed sometimes when tethering is used over NCM with Windows 11as host, at some instances, the gadget_giveback has one byte appended atthe end of a proper NTB. When the NTB is parsed, unwrap call looks forany leftover bytes in SKB provided by u_ether and if there are any pendingbytes, it treats them as a separate NTB and parses it. But in case thesecond NTB (as per unwrap call) is faulty/corrupt, all the datagrams thatwere parsed properly in the first NTB and saved in rx_list are dropped.Adding a few custom traces showed the following:[002] d..1  7828.532866: dwc3_gadget_giveback: ep1out:req 000000003868811a length 1025/16384 zsI ==&gt; 0[002] d..1  7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb toprocess: 1025[002] d..1  7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342[002] d..1  7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb seq: 0xce67[002] d..1  7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x400[002] d..1  7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb ndp_len: 0x10[002] d..1  7828.532869: ncm_unwrap_ntb: K: Parsed NTB with 1 framesIn this case, the giveback is of 1025 bytes and block length is 1024.The rest 1 byte (which is 0x00) won&#39;t be parsed resulting in drop ofall datagrams in rx_list.Same is case with packets of size 2048:[002] d..1  7828.557948: dwc3_gadget_giveback: ep1out:req 0000000011dfd96e length 2049/16384 zsI ==&gt; 0[002] d..1  7828.557949: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342[002] d..1  7828.557950: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x800Lecroy shows one byte coming in extra confirming that the byte is comingin from PC: Transfer 2959 - Bytes Transferred(1025)  Timestamp((18.524 843 590) - Transaction 8391 - Data(1025 bytes) Timestamp(18.524 843 590) --- Packet 4063861       Data(1024 bytes)       Duration(2.117us) Idle(14.700ns) Timestamp(18.524 843 590) --- Packet 4063863       Data(1 byte)       Duration(66.160ns) Time(282.000ns) Timestamp(18.524 845 722)According to Windows driver, no ZLP is needed if wBlockLength is non-zero,because the non-zero wBlockLength has already told the function side thesize of transfer to be expected. However, there are in-market NCM devicesthat rely on ZLP as long as the wBlockLength is multiple of wMaxPacketSize.To deal with such devices, it pads an extra 0 at end so the transfer is nolonger multiple of wMaxPacketSize.(CVE-2024-27405)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: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: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: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 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)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="bpftool" release="217.0.0.116.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-217.0.0.116.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="217.0.0.116.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-217.0.0.116.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="217.0.0.116.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-217.0.0.116.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="217.0.0.116.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-217.0.0.116.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="217.0.0.116.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-217.0.0.116.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="217.0.0.116.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-217.0.0.116.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="217.0.0.116.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-217.0.0.116.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="217.0.0.116.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-217.0.0.116.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="217.0.0.116.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-217.0.0.116.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="217.0.0.116.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-217.0.0.116.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="217.0.0.116.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-217.0.0.116.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="217.0.0.116.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-217.0.0.116.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="217.0.0.116.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-217.0.0.116.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="217.0.0.116.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-217.0.0.116.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="217.0.0.116.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-217.0.0.116.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="217.0.0.116.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-217.0.0.116.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="217.0.0.116.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-217.0.0.116.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="217.0.0.116.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-217.0.0.116.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="217.0.0.116.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-217.0.0.116.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="217.0.0.116.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-217.0.0.116.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="217.0.0.116.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-217.0.0.116.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="217.0.0.116.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-217.0.0.116.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="217.0.0.116.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-217.0.0.116.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="217.0.0.116.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-217.0.0.116.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="217.0.0.116.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-217.0.0.116.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="217.0.0.116.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-217.0.0.116.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="217.0.0.116.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-217.0.0.116.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="217.0.0.116.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-217.0.0.116.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="217.0.0.116.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-217.0.0.116.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="217.0.0.116.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-217.0.0.116.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1798</id>
          <title>An update for rubygem-activesupport is now available for openEuler-22.03-LTS-SP4</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.oe2203sp4" version="6.1.4.1">
                         <filename>rubygem-activesupport-6.1.4.1-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="rubygem-activesupport-doc" release="8.oe2203sp4" version="6.1.4.1">
                         <filename>rubygem-activesupport-doc-6.1.4.1-8.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1806</id>
          <title>An update for ffmpeg is now available for openEuler-22.03-LTS-SP4</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="13.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-4.2.4-13.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ffmpeg-debuginfo" release="13.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-debuginfo-4.2.4-13.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ffmpeg-debugsource" release="13.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-debugsource-4.2.4-13.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ffmpeg-devel" release="13.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-devel-4.2.4-13.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ffmpeg-libs" release="13.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-libs-4.2.4-13.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libavdevice" release="13.oe2203sp4" version="4.2.4">
                         <filename>libavdevice-4.2.4-13.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg" release="13.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-4.2.4-13.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg-debuginfo" release="13.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-debuginfo-4.2.4-13.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg-debugsource" release="13.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-debugsource-4.2.4-13.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg-devel" release="13.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-devel-4.2.4-13.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg-libs" release="13.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-libs-4.2.4-13.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libavdevice" release="13.oe2203sp4" version="4.2.4">
                         <filename>libavdevice-4.2.4-13.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1810</id>
          <title>An update for rubygem-actionpack is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-07-05"></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.oe2203sp4" version="6.1.4.1">
                         <filename>rubygem-actionpack-6.1.4.1-6.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="rubygem-actionpack-doc" release="6.oe2203sp4" version="6.1.4.1">
                         <filename>rubygem-actionpack-doc-6.1.4.1-6.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1813</id>
          <title>An update for poppler is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-07-05"></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.oe2203sp4" version="0.90.0">
                         <filename>poppler-0.90.0-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-cpp" release="8.oe2203sp4" version="0.90.0">
                         <filename>poppler-cpp-0.90.0-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-cpp-devel" release="8.oe2203sp4" version="0.90.0">
                         <filename>poppler-cpp-devel-0.90.0-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-debuginfo" release="8.oe2203sp4" version="0.90.0">
                         <filename>poppler-debuginfo-0.90.0-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-debugsource" release="8.oe2203sp4" version="0.90.0">
                         <filename>poppler-debugsource-0.90.0-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-devel" release="8.oe2203sp4" version="0.90.0">
                         <filename>poppler-devel-0.90.0-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-glib" release="8.oe2203sp4" version="0.90.0">
                         <filename>poppler-glib-0.90.0-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-glib-devel" release="8.oe2203sp4" version="0.90.0">
                         <filename>poppler-glib-devel-0.90.0-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-qt5" release="8.oe2203sp4" version="0.90.0">
                         <filename>poppler-qt5-0.90.0-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-qt5-devel" release="8.oe2203sp4" version="0.90.0">
                         <filename>poppler-qt5-devel-0.90.0-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-utils" release="8.oe2203sp4" version="0.90.0">
                         <filename>poppler-utils-0.90.0-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="poppler-glib-doc" release="8.oe2203sp4" version="0.90.0">
                         <filename>poppler-glib-doc-0.90.0-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="poppler-help" release="8.oe2203sp4" version="0.90.0">
                         <filename>poppler-help-0.90.0-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler" release="8.oe2203sp4" version="0.90.0">
                         <filename>poppler-0.90.0-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-cpp" release="8.oe2203sp4" version="0.90.0">
                         <filename>poppler-cpp-0.90.0-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-cpp-devel" release="8.oe2203sp4" version="0.90.0">
                         <filename>poppler-cpp-devel-0.90.0-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-debuginfo" release="8.oe2203sp4" version="0.90.0">
                         <filename>poppler-debuginfo-0.90.0-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-debugsource" release="8.oe2203sp4" version="0.90.0">
                         <filename>poppler-debugsource-0.90.0-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-devel" release="8.oe2203sp4" version="0.90.0">
                         <filename>poppler-devel-0.90.0-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-glib" release="8.oe2203sp4" version="0.90.0">
                         <filename>poppler-glib-0.90.0-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-glib-devel" release="8.oe2203sp4" version="0.90.0">
                         <filename>poppler-glib-devel-0.90.0-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-qt5" release="8.oe2203sp4" version="0.90.0">
                         <filename>poppler-qt5-0.90.0-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-qt5-devel" release="8.oe2203sp4" version="0.90.0">
                         <filename>poppler-qt5-devel-0.90.0-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-utils" release="8.oe2203sp4" version="0.90.0">
                         <filename>poppler-utils-0.90.0-8.oe2203sp4.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-SP4</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 epoch="1" arch="aarch64" name="emacs" release="14.oe2203sp4" version="27.2">
                         <filename>emacs-27.2-14.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="emacs-common" release="14.oe2203sp4" version="27.2">
                         <filename>emacs-common-27.2-14.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="emacs-debuginfo" release="14.oe2203sp4" version="27.2">
                         <filename>emacs-debuginfo-27.2-14.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="emacs-debugsource" release="14.oe2203sp4" version="27.2">
                         <filename>emacs-debugsource-27.2-14.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="emacs-devel" release="14.oe2203sp4" version="27.2">
                         <filename>emacs-devel-27.2-14.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="emacs-lucid" release="14.oe2203sp4" version="27.2">
                         <filename>emacs-lucid-27.2-14.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="emacs-nox" release="14.oe2203sp4" version="27.2">
                         <filename>emacs-nox-27.2-14.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="emacs-filesystem" release="14.oe2203sp4" version="27.2">
                         <filename>emacs-filesystem-27.2-14.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="emacs-help" release="14.oe2203sp4" version="27.2">
                         <filename>emacs-help-27.2-14.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="emacs-terminal" release="14.oe2203sp4" version="27.2">
                         <filename>emacs-terminal-27.2-14.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="emacs" release="14.oe2203sp4" version="27.2">
                         <filename>emacs-27.2-14.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="emacs-common" release="14.oe2203sp4" version="27.2">
                         <filename>emacs-common-27.2-14.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="emacs-debuginfo" release="14.oe2203sp4" version="27.2">
                         <filename>emacs-debuginfo-27.2-14.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="emacs-debugsource" release="14.oe2203sp4" version="27.2">
                         <filename>emacs-debugsource-27.2-14.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="emacs-devel" release="14.oe2203sp4" version="27.2">
                         <filename>emacs-devel-27.2-14.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="emacs-lucid" release="14.oe2203sp4" version="27.2">
                         <filename>emacs-lucid-27.2-14.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="emacs-nox" release="14.oe2203sp4" version="27.2">
                         <filename>emacs-nox-27.2-14.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1817</id>
          <title>An update for xorg-x11-server-xwayland is now available for openEuler-22.03-LTS-SP4</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.oe2203sp4" version="22.1.2">
                         <filename>xorg-x11-server-Xwayland-22.1.2-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-Xwayland-debuginfo" release="6.oe2203sp4" version="22.1.2">
                         <filename>xorg-x11-server-Xwayland-debuginfo-22.1.2-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-Xwayland-debugsource" release="6.oe2203sp4" version="22.1.2">
                         <filename>xorg-x11-server-Xwayland-debugsource-22.1.2-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-Xwayland-devel" release="6.oe2203sp4" version="22.1.2">
                         <filename>xorg-x11-server-Xwayland-devel-22.1.2-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xwayland" release="6.oe2203sp4" version="22.1.2">
                         <filename>xorg-x11-server-Xwayland-22.1.2-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xwayland-debuginfo" release="6.oe2203sp4" version="22.1.2">
                         <filename>xorg-x11-server-Xwayland-debuginfo-22.1.2-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xwayland-debugsource" release="6.oe2203sp4" version="22.1.2">
                         <filename>xorg-x11-server-Xwayland-debugsource-22.1.2-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xwayland-devel" release="6.oe2203sp4" version="22.1.2">
                         <filename>xorg-x11-server-Xwayland-devel-22.1.2-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1821</id>
          <title>An update for rubygem-rack is now available for openEuler-22.03-LTS-SP4</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="5.oe2203sp4" version="2.2.3.1">
                         <filename>rubygem-rack-2.2.3.1-5.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="rubygem-rack-help" release="5.oe2203sp4" version="2.2.3.1">
                         <filename>rubygem-rack-help-2.2.3.1-5.oe2203sp4.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-SP4</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.oe2203sp4" version="3.0.3">
                         <filename>ruby-3.0.3-136.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ruby-debuginfo" release="136.oe2203sp4" version="3.0.3">
                         <filename>ruby-debuginfo-3.0.3-136.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ruby-debugsource" release="136.oe2203sp4" version="3.0.3">
                         <filename>ruby-debugsource-3.0.3-136.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ruby-devel" release="136.oe2203sp4" version="3.0.3">
                         <filename>ruby-devel-3.0.3-136.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-bigdecimal" release="136.oe2203sp4" version="3.0.0">
                         <filename>rubygem-bigdecimal-3.0.0-136.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-io-console" release="136.oe2203sp4" version="0.5.7">
                         <filename>rubygem-io-console-0.5.7-136.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-json" release="136.oe2203sp4" version="2.5.1">
                         <filename>rubygem-json-2.5.1-136.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-openssl" release="136.oe2203sp4" version="2.2.1">
                         <filename>rubygem-openssl-2.2.1-136.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-psych" release="136.oe2203sp4" version="3.3.2">
                         <filename>rubygem-psych-3.3.2-136.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="ruby-help" release="136.oe2203sp4" version="3.0.3">
                         <filename>ruby-help-3.0.3-136.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="ruby-irb" release="136.oe2203sp4" version="3.0.3">
                         <filename>ruby-irb-3.0.3-136.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-bundler" release="136.oe2203sp4" version="2.2.32">
                         <filename>rubygem-bundler-2.2.32-136.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-did_you_mean" release="136.oe2203sp4" version="1.5.0">
                         <filename>rubygem-did_you_mean-1.5.0-136.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-minitest" release="136.oe2203sp4" version="5.14.2">
                         <filename>rubygem-minitest-5.14.2-136.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rake" release="136.oe2203sp4" version="13.0.3">
                         <filename>rubygem-rake-13.0.3-136.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rbs" release="136.oe2203sp4" version="1.4.0">
                         <filename>rubygem-rbs-1.4.0-136.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rdoc" release="136.oe2203sp4" version="6.3.3">
                         <filename>rubygem-rdoc-6.3.3-136.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rexml" release="136.oe2203sp4" version="3.2.5">
                         <filename>rubygem-rexml-3.2.5-136.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rss" release="136.oe2203sp4" version="0.2.9">
                         <filename>rubygem-rss-0.2.9-136.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-test-unit" release="136.oe2203sp4" version="3.3.7">
                         <filename>rubygem-test-unit-3.3.7-136.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-typeprof" release="136.oe2203sp4" version="0.15.2">
                         <filename>rubygem-typeprof-0.15.2-136.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygems" release="136.oe2203sp4" version="3.2.32">
                         <filename>rubygems-3.2.32-136.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygems-devel" release="136.oe2203sp4" version="3.2.32">
                         <filename>rubygems-devel-3.2.32-136.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby" release="136.oe2203sp4" version="3.0.3">
                         <filename>ruby-3.0.3-136.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby-debuginfo" release="136.oe2203sp4" version="3.0.3">
                         <filename>ruby-debuginfo-3.0.3-136.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby-debugsource" release="136.oe2203sp4" version="3.0.3">
                         <filename>ruby-debugsource-3.0.3-136.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby-devel" release="136.oe2203sp4" version="3.0.3">
                         <filename>ruby-devel-3.0.3-136.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-bigdecimal" release="136.oe2203sp4" version="3.0.0">
                         <filename>rubygem-bigdecimal-3.0.0-136.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-io-console" release="136.oe2203sp4" version="0.5.7">
                         <filename>rubygem-io-console-0.5.7-136.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-json" release="136.oe2203sp4" version="2.5.1">
                         <filename>rubygem-json-2.5.1-136.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-openssl" release="136.oe2203sp4" version="2.2.1">
                         <filename>rubygem-openssl-2.2.1-136.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-psych" release="136.oe2203sp4" version="3.3.2">
                         <filename>rubygem-psych-3.3.2-136.oe2203sp4.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-SP4</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.oe2203sp4" version="1.19.2">
                         <filename>krb5-1.19.2-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="krb5-client" release="17.oe2203sp4" version="1.19.2">
                         <filename>krb5-client-1.19.2-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="krb5-debuginfo" release="17.oe2203sp4" version="1.19.2">
                         <filename>krb5-debuginfo-1.19.2-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="krb5-debugsource" release="17.oe2203sp4" version="1.19.2">
                         <filename>krb5-debugsource-1.19.2-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="krb5-devel" release="17.oe2203sp4" version="1.19.2">
                         <filename>krb5-devel-1.19.2-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="krb5-libs" release="17.oe2203sp4" version="1.19.2">
                         <filename>krb5-libs-1.19.2-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="krb5-server" release="17.oe2203sp4" version="1.19.2">
                         <filename>krb5-server-1.19.2-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="krb5-help" release="17.oe2203sp4" version="1.19.2">
                         <filename>krb5-help-1.19.2-17.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="krb5" release="17.oe2203sp4" version="1.19.2">
                         <filename>krb5-1.19.2-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="krb5-client" release="17.oe2203sp4" version="1.19.2">
                         <filename>krb5-client-1.19.2-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="krb5-debuginfo" release="17.oe2203sp4" version="1.19.2">
                         <filename>krb5-debuginfo-1.19.2-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="krb5-debugsource" release="17.oe2203sp4" version="1.19.2">
                         <filename>krb5-debugsource-1.19.2-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="krb5-devel" release="17.oe2203sp4" version="1.19.2">
                         <filename>krb5-devel-1.19.2-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="krb5-libs" release="17.oe2203sp4" version="1.19.2">
                         <filename>krb5-libs-1.19.2-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="krb5-server" release="17.oe2203sp4" version="1.19.2">
                         <filename>krb5-server-1.19.2-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1828</id>
          <title>An update for vte291 is now available for openEuler-22.03-LTS-SP4</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.oe2203sp4" version="0.62.3">
                         <filename>vte291-0.62.3-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="vte291-debuginfo" release="2.oe2203sp4" version="0.62.3">
                         <filename>vte291-debuginfo-0.62.3-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="vte291-debugsource" release="2.oe2203sp4" version="0.62.3">
                         <filename>vte291-debugsource-0.62.3-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="vte291-devel" release="2.oe2203sp4" version="0.62.3">
                         <filename>vte291-devel-0.62.3-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="vte291" release="2.oe2203sp4" version="0.62.3">
                         <filename>vte291-0.62.3-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="vte291-debuginfo" release="2.oe2203sp4" version="0.62.3">
                         <filename>vte291-debuginfo-0.62.3-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="vte291-debugsource" release="2.oe2203sp4" version="0.62.3">
                         <filename>vte291-debugsource-0.62.3-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="vte291-devel" release="2.oe2203sp4" version="0.62.3">
                         <filename>vte291-devel-0.62.3-2.oe2203sp4.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-SP4</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.oe2203sp4" version="2.4.51">
                         <filename>httpd-2.4.51-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd-debuginfo" release="22.oe2203sp4" version="2.4.51">
                         <filename>httpd-debuginfo-2.4.51-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd-debugsource" release="22.oe2203sp4" version="2.4.51">
                         <filename>httpd-debugsource-2.4.51-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd-devel" release="22.oe2203sp4" version="2.4.51">
                         <filename>httpd-devel-2.4.51-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd-tools" release="22.oe2203sp4" version="2.4.51">
                         <filename>httpd-tools-2.4.51-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_ldap" release="22.oe2203sp4" version="2.4.51">
                         <filename>mod_ldap-2.4.51-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_md" release="22.oe2203sp4" version="2.4.51">
                         <filename>mod_md-2.4.51-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mod_proxy_html" release="22.oe2203sp4" version="2.4.51">
                         <filename>mod_proxy_html-2.4.51-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_session" release="22.oe2203sp4" version="2.4.51">
                         <filename>mod_session-2.4.51-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mod_ssl" release="22.oe2203sp4" version="2.4.51">
                         <filename>mod_ssl-2.4.51-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="httpd-filesystem" release="22.oe2203sp4" version="2.4.51">
                         <filename>httpd-filesystem-2.4.51-22.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="httpd-help" release="22.oe2203sp4" version="2.4.51">
                         <filename>httpd-help-2.4.51-22.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd" release="22.oe2203sp4" version="2.4.51">
                         <filename>httpd-2.4.51-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-debuginfo" release="22.oe2203sp4" version="2.4.51">
                         <filename>httpd-debuginfo-2.4.51-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-debugsource" release="22.oe2203sp4" version="2.4.51">
                         <filename>httpd-debugsource-2.4.51-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-devel" release="22.oe2203sp4" version="2.4.51">
                         <filename>httpd-devel-2.4.51-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-tools" release="22.oe2203sp4" version="2.4.51">
                         <filename>httpd-tools-2.4.51-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_ldap" release="22.oe2203sp4" version="2.4.51">
                         <filename>mod_ldap-2.4.51-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_md" release="22.oe2203sp4" version="2.4.51">
                         <filename>mod_md-2.4.51-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mod_proxy_html" release="22.oe2203sp4" version="2.4.51">
                         <filename>mod_proxy_html-2.4.51-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_session" release="22.oe2203sp4" version="2.4.51">
                         <filename>mod_session-2.4.51-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mod_ssl" release="22.oe2203sp4" version="2.4.51">
                         <filename>mod_ssl-2.4.51-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1831</id>
          <title>An update for ffmpeg is now available for openEuler-22.03-LTS-SP4</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>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3341" id="CVE-2022-3341" title="CVE-2022-3341" 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)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)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="ffmpeg" release="14.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-4.2.4-14.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ffmpeg-debuginfo" release="14.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-debuginfo-4.2.4-14.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ffmpeg-debugsource" release="14.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-debugsource-4.2.4-14.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ffmpeg-devel" release="14.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-devel-4.2.4-14.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ffmpeg-libs" release="14.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-libs-4.2.4-14.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libavdevice" release="14.oe2203sp4" version="4.2.4">
                         <filename>libavdevice-4.2.4-14.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg" release="14.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-4.2.4-14.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg-debuginfo" release="14.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-debuginfo-4.2.4-14.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg-debugsource" release="14.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-debugsource-4.2.4-14.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg-devel" release="14.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-devel-4.2.4-14.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg-libs" release="14.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-libs-4.2.4-14.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libavdevice" release="14.oe2203sp4" version="4.2.4">
                         <filename>libavdevice-4.2.4-14.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1837</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP4</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-2024-38554" id="CVE-2024-38554" title="CVE-2024-38554" 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-38625" id="CVE-2024-38625" title="CVE-2024-38625" 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: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: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:fs/ntfs3: Check &#39;folio&#39; pointer for NULLIt can be NULL if bmap is called.(CVE-2024-38625)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="bpftool" release="218.0.0.117.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-218.0.0.117.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="218.0.0.117.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-218.0.0.117.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="218.0.0.117.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-218.0.0.117.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="218.0.0.117.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-218.0.0.117.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="218.0.0.117.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-218.0.0.117.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="218.0.0.117.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-218.0.0.117.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="218.0.0.117.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-218.0.0.117.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="218.0.0.117.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-218.0.0.117.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="218.0.0.117.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-218.0.0.117.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="218.0.0.117.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-218.0.0.117.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="218.0.0.117.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-218.0.0.117.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="218.0.0.117.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-218.0.0.117.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="218.0.0.117.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-218.0.0.117.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="218.0.0.117.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-218.0.0.117.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="218.0.0.117.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-218.0.0.117.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="218.0.0.117.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-218.0.0.117.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="218.0.0.117.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-218.0.0.117.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="218.0.0.117.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-218.0.0.117.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="218.0.0.117.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-218.0.0.117.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="218.0.0.117.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-218.0.0.117.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="218.0.0.117.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-218.0.0.117.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="218.0.0.117.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-218.0.0.117.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="218.0.0.117.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-218.0.0.117.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="218.0.0.117.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-218.0.0.117.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="218.0.0.117.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-218.0.0.117.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="218.0.0.117.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-218.0.0.117.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="218.0.0.117.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-218.0.0.117.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="218.0.0.117.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-218.0.0.117.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="218.0.0.117.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-218.0.0.117.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="218.0.0.117.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-218.0.0.117.oe2203sp4.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-SP4</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.oe2203sp4" version="2.5.5">
                         <filename>openvpn-2.5.5-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openvpn-debuginfo" release="3.oe2203sp4" version="2.5.5">
                         <filename>openvpn-debuginfo-2.5.5-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openvpn-debugsource" release="3.oe2203sp4" version="2.5.5">
                         <filename>openvpn-debugsource-2.5.5-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openvpn-devel" release="3.oe2203sp4" version="2.5.5">
                         <filename>openvpn-devel-2.5.5-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="openvpn-help" release="3.oe2203sp4" version="2.5.5">
                         <filename>openvpn-help-2.5.5-3.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openvpn" release="3.oe2203sp4" version="2.5.5">
                         <filename>openvpn-2.5.5-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openvpn-debuginfo" release="3.oe2203sp4" version="2.5.5">
                         <filename>openvpn-debuginfo-2.5.5-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openvpn-debugsource" release="3.oe2203sp4" version="2.5.5">
                         <filename>openvpn-debugsource-2.5.5-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openvpn-devel" release="3.oe2203sp4" version="2.5.5">
                         <filename>openvpn-devel-2.5.5-3.oe2203sp4.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-SP4</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.oe2203sp4" version="178">
                         <filename>cockpit-178-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="cockpit-debuginfo" release="17.oe2203sp4" version="178">
                         <filename>cockpit-debuginfo-178-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="cockpit-debugsource" release="17.oe2203sp4" version="178">
                         <filename>cockpit-debugsource-178-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="cockpit-devel" release="17.oe2203sp4" version="178">
                         <filename>cockpit-devel-178-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="cockpit-cockpit-machines" release="17.oe2203sp4" version="178">
                         <filename>cockpit-cockpit-machines-178-17.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="cockpit-cockpit-machines-ovirt" release="17.oe2203sp4" version="178">
                         <filename>cockpit-cockpit-machines-ovirt-178-17.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="cockpit-help" release="17.oe2203sp4" version="178">
                         <filename>cockpit-help-178-17.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cockpit" release="17.oe2203sp4" version="178">
                         <filename>cockpit-178-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cockpit-debuginfo" release="17.oe2203sp4" version="178">
                         <filename>cockpit-debuginfo-178-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cockpit-debugsource" release="17.oe2203sp4" version="178">
                         <filename>cockpit-debugsource-178-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cockpit-devel" release="17.oe2203sp4" version="178">
                         <filename>cockpit-devel-178-17.oe2203sp4.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-SP4</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.oe2203sp4" version="2.5.0">
                         <filename>openjpeg2-2.5.0-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openjpeg2-debuginfo" release="3.oe2203sp4" version="2.5.0">
                         <filename>openjpeg2-debuginfo-2.5.0-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openjpeg2-debugsource" release="3.oe2203sp4" version="2.5.0">
                         <filename>openjpeg2-debugsource-2.5.0-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openjpeg2-devel" release="3.oe2203sp4" version="2.5.0">
                         <filename>openjpeg2-devel-2.5.0-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openjpeg2-tools" release="3.oe2203sp4" version="2.5.0">
                         <filename>openjpeg2-tools-2.5.0-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="openjpeg2-help" release="3.oe2203sp4" version="2.5.0">
                         <filename>openjpeg2-help-2.5.0-3.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openjpeg2" release="3.oe2203sp4" version="2.5.0">
                         <filename>openjpeg2-2.5.0-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openjpeg2-debuginfo" release="3.oe2203sp4" version="2.5.0">
                         <filename>openjpeg2-debuginfo-2.5.0-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openjpeg2-debugsource" release="3.oe2203sp4" version="2.5.0">
                         <filename>openjpeg2-debugsource-2.5.0-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openjpeg2-devel" release="3.oe2203sp4" version="2.5.0">
                         <filename>openjpeg2-devel-2.5.0-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openjpeg2-tools" release="3.oe2203sp4" version="2.5.0">
                         <filename>openjpeg2-tools-2.5.0-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1848</id>
          <title>An update for arm-trusted-firmware is now available for openEuler-22.03-LTS-SP4</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.oe2203sp4" version="2.3">
                         <filename>arm-trusted-firmware-armv8-2.3-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1855</id>
          <title>An update for httpd is now available for openEuler-22.03-LTS-SP4</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.oe2203sp4" version="2.4.51">
                         <filename>httpd-2.4.51-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd-debuginfo" release="22.oe2203sp4" version="2.4.51">
                         <filename>httpd-debuginfo-2.4.51-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd-debugsource" release="22.oe2203sp4" version="2.4.51">
                         <filename>httpd-debugsource-2.4.51-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd-devel" release="22.oe2203sp4" version="2.4.51">
                         <filename>httpd-devel-2.4.51-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd-tools" release="22.oe2203sp4" version="2.4.51">
                         <filename>httpd-tools-2.4.51-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_ldap" release="22.oe2203sp4" version="2.4.51">
                         <filename>mod_ldap-2.4.51-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_md" release="22.oe2203sp4" version="2.4.51">
                         <filename>mod_md-2.4.51-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mod_proxy_html" release="22.oe2203sp4" version="2.4.51">
                         <filename>mod_proxy_html-2.4.51-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_session" release="22.oe2203sp4" version="2.4.51">
                         <filename>mod_session-2.4.51-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mod_ssl" release="22.oe2203sp4" version="2.4.51">
                         <filename>mod_ssl-2.4.51-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="httpd-filesystem" release="22.oe2203sp4" version="2.4.51">
                         <filename>httpd-filesystem-2.4.51-22.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="httpd-help" release="22.oe2203sp4" version="2.4.51">
                         <filename>httpd-help-2.4.51-22.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd" release="22.oe2203sp4" version="2.4.51">
                         <filename>httpd-2.4.51-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-debuginfo" release="22.oe2203sp4" version="2.4.51">
                         <filename>httpd-debuginfo-2.4.51-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-debugsource" release="22.oe2203sp4" version="2.4.51">
                         <filename>httpd-debugsource-2.4.51-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-devel" release="22.oe2203sp4" version="2.4.51">
                         <filename>httpd-devel-2.4.51-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-tools" release="22.oe2203sp4" version="2.4.51">
                         <filename>httpd-tools-2.4.51-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_ldap" release="22.oe2203sp4" version="2.4.51">
                         <filename>mod_ldap-2.4.51-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_md" release="22.oe2203sp4" version="2.4.51">
                         <filename>mod_md-2.4.51-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mod_proxy_html" release="22.oe2203sp4" version="2.4.51">
                         <filename>mod_proxy_html-2.4.51-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_session" release="22.oe2203sp4" version="2.4.51">
                         <filename>mod_session-2.4.51-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mod_ssl" release="22.oe2203sp4" version="2.4.51">
                         <filename>mod_ssl-2.4.51-22.oe2203sp4.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-SP4</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="12.oe2203sp4" version="1.1.0">
                         <filename>rapidjson-devel-1.1.0-12.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rapidjson-help" release="12.oe2203sp4" version="1.1.0">
                         <filename>rapidjson-help-1.1.0-12.oe2203sp4.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-SP4</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 epoch="10" arch="aarch64" name="qemu" release="96.oe2203sp4" version="6.2.0">
                         <filename>qemu-6.2.0-96.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-curl" release="96.oe2203sp4" version="6.2.0">
                         <filename>qemu-block-curl-6.2.0-96.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-iscsi" release="96.oe2203sp4" version="6.2.0">
                         <filename>qemu-block-iscsi-6.2.0-96.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-rbd" release="96.oe2203sp4" version="6.2.0">
                         <filename>qemu-block-rbd-6.2.0-96.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-ssh" release="96.oe2203sp4" version="6.2.0">
                         <filename>qemu-block-ssh-6.2.0-96.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-debuginfo" release="96.oe2203sp4" version="6.2.0">
                         <filename>qemu-debuginfo-6.2.0-96.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-debugsource" release="96.oe2203sp4" version="6.2.0">
                         <filename>qemu-debugsource-6.2.0-96.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-guest-agent" release="96.oe2203sp4" version="6.2.0">
                         <filename>qemu-guest-agent-6.2.0-96.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-hw-usb-host" release="96.oe2203sp4" version="6.2.0">
                         <filename>qemu-hw-usb-host-6.2.0-96.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-img" release="96.oe2203sp4" version="6.2.0">
                         <filename>qemu-img-6.2.0-96.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-aarch64" release="96.oe2203sp4" version="6.2.0">
                         <filename>qemu-system-aarch64-6.2.0-96.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-arm" release="96.oe2203sp4" version="6.2.0">
                         <filename>qemu-system-arm-6.2.0-96.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-riscv" release="96.oe2203sp4" version="6.2.0">
                         <filename>qemu-system-riscv-6.2.0-96.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-x86_64" release="96.oe2203sp4" version="6.2.0">
                         <filename>qemu-system-x86_64-6.2.0-96.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="noarch" name="qemu-help" release="96.oe2203sp4" version="6.2.0">
                         <filename>qemu-help-6.2.0-96.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu" release="96.oe2203sp4" version="6.2.0">
                         <filename>qemu-6.2.0-96.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-curl" release="96.oe2203sp4" version="6.2.0">
                         <filename>qemu-block-curl-6.2.0-96.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-iscsi" release="96.oe2203sp4" version="6.2.0">
                         <filename>qemu-block-iscsi-6.2.0-96.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-rbd" release="96.oe2203sp4" version="6.2.0">
                         <filename>qemu-block-rbd-6.2.0-96.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-ssh" release="96.oe2203sp4" version="6.2.0">
                         <filename>qemu-block-ssh-6.2.0-96.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-debuginfo" release="96.oe2203sp4" version="6.2.0">
                         <filename>qemu-debuginfo-6.2.0-96.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-debugsource" release="96.oe2203sp4" version="6.2.0">
                         <filename>qemu-debugsource-6.2.0-96.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-guest-agent" release="96.oe2203sp4" version="6.2.0">
                         <filename>qemu-guest-agent-6.2.0-96.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-hw-usb-host" release="96.oe2203sp4" version="6.2.0">
                         <filename>qemu-hw-usb-host-6.2.0-96.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-img" release="96.oe2203sp4" version="6.2.0">
                         <filename>qemu-img-6.2.0-96.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-seabios" release="96.oe2203sp4" version="6.2.0">
                         <filename>qemu-seabios-6.2.0-96.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-aarch64" release="96.oe2203sp4" version="6.2.0">
                         <filename>qemu-system-aarch64-6.2.0-96.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-arm" release="96.oe2203sp4" version="6.2.0">
                         <filename>qemu-system-arm-6.2.0-96.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-riscv" release="96.oe2203sp4" version="6.2.0">
                         <filename>qemu-system-riscv-6.2.0-96.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-x86_64" release="96.oe2203sp4" version="6.2.0">
                         <filename>qemu-system-x86_64-6.2.0-96.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1864</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-07-19"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38540" id="CVE-2024-38540" title="CVE-2024-38540" type="cve"></reference>
          </references>
          <description>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)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="bpftool" release="219.0.0.118.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-219.0.0.118.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="219.0.0.118.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-219.0.0.118.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="219.0.0.118.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-219.0.0.118.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="219.0.0.118.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-219.0.0.118.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="219.0.0.118.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-219.0.0.118.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="219.0.0.118.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-219.0.0.118.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="219.0.0.118.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-219.0.0.118.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="219.0.0.118.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-219.0.0.118.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="219.0.0.118.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-219.0.0.118.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="219.0.0.118.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-219.0.0.118.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="219.0.0.118.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-219.0.0.118.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="219.0.0.118.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-219.0.0.118.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="219.0.0.118.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-219.0.0.118.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="219.0.0.118.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-219.0.0.118.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="219.0.0.118.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-219.0.0.118.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="219.0.0.118.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-219.0.0.118.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="219.0.0.118.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-219.0.0.118.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="219.0.0.118.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-219.0.0.118.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="219.0.0.118.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-219.0.0.118.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="219.0.0.118.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-219.0.0.118.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="219.0.0.118.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-219.0.0.118.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="219.0.0.118.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-219.0.0.118.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="219.0.0.118.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-219.0.0.118.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="219.0.0.118.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-219.0.0.118.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="219.0.0.118.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-219.0.0.118.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="219.0.0.118.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-219.0.0.118.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="219.0.0.118.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-219.0.0.118.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="219.0.0.118.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-219.0.0.118.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="219.0.0.118.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-219.0.0.118.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="219.0.0.118.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-219.0.0.118.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1866</id>
          <title>An update for python-pip is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-07-19"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45803" id="CVE-2023-45803" title="CVE-2023-45803" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-37891" id="CVE-2024-37891" title="CVE-2024-37891" type="cve"></reference>
          </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) 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="8.oe2203sp4" version="21.3.1">
                         <filename>python-pip-help-21.3.1-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python-pip-wheel" release="8.oe2203sp4" version="21.3.1">
                         <filename>python-pip-wheel-21.3.1-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-pip" release="8.oe2203sp4" version="21.3.1">
                         <filename>python3-pip-21.3.1-8.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1872</id>
          <title>An update for openssh is now available for openEuler-22.03-LTS-SP4</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.oe2203sp4" version="8.8p1">
                         <filename>openssh-8.8p1-32.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-askpass" release="32.oe2203sp4" version="8.8p1">
                         <filename>openssh-askpass-8.8p1-32.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-clients" release="32.oe2203sp4" version="8.8p1">
                         <filename>openssh-clients-8.8p1-32.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-debuginfo" release="32.oe2203sp4" version="8.8p1">
                         <filename>openssh-debuginfo-8.8p1-32.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-debugsource" release="32.oe2203sp4" version="8.8p1">
                         <filename>openssh-debugsource-8.8p1-32.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-keycat" release="32.oe2203sp4" version="8.8p1">
                         <filename>openssh-keycat-8.8p1-32.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-server" release="32.oe2203sp4" version="8.8p1">
                         <filename>openssh-server-8.8p1-32.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pam_ssh_agent_auth" release="4.32.oe2203sp4" version="0.10.4">
                         <filename>pam_ssh_agent_auth-0.10.4-4.32.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="openssh-help" release="32.oe2203sp4" version="8.8p1">
                         <filename>openssh-help-8.8p1-32.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh" release="32.oe2203sp4" version="8.8p1">
                         <filename>openssh-8.8p1-32.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-askpass" release="32.oe2203sp4" version="8.8p1">
                         <filename>openssh-askpass-8.8p1-32.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-clients" release="32.oe2203sp4" version="8.8p1">
                         <filename>openssh-clients-8.8p1-32.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-debuginfo" release="32.oe2203sp4" version="8.8p1">
                         <filename>openssh-debuginfo-8.8p1-32.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-debugsource" release="32.oe2203sp4" version="8.8p1">
                         <filename>openssh-debugsource-8.8p1-32.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-keycat" release="32.oe2203sp4" version="8.8p1">
                         <filename>openssh-keycat-8.8p1-32.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-server" release="32.oe2203sp4" version="8.8p1">
                         <filename>openssh-server-8.8p1-32.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pam_ssh_agent_auth" release="4.32.oe2203sp4" version="0.10.4">
                         <filename>pam_ssh_agent_auth-0.10.4-4.32.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1875</id>
          <title>An update for ffmpeg is now available for openEuler-22.03-LTS-SP4</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.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-4.2.4-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ffmpeg-debuginfo" release="17.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-debuginfo-4.2.4-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ffmpeg-debugsource" release="17.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-debugsource-4.2.4-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ffmpeg-devel" release="17.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-devel-4.2.4-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ffmpeg-libs" release="17.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-libs-4.2.4-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libavdevice" release="17.oe2203sp4" version="4.2.4">
                         <filename>libavdevice-4.2.4-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg" release="17.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-4.2.4-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg-debuginfo" release="17.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-debuginfo-4.2.4-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg-debugsource" release="17.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-debugsource-4.2.4-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg-devel" release="17.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-devel-4.2.4-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg-libs" release="17.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-libs-4.2.4-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libavdevice" release="17.oe2203sp4" version="4.2.4">
                         <filename>libavdevice-4.2.4-17.oe2203sp4.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-SP4</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.oe2203sp4" version="3.0.25">
                         <filename>freeradius-3.0.25-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="freeradius-debuginfo" release="3.oe2203sp4" version="3.0.25">
                         <filename>freeradius-debuginfo-3.0.25-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="freeradius-debugsource" release="3.oe2203sp4" version="3.0.25">
                         <filename>freeradius-debugsource-3.0.25-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="freeradius-devel" release="3.oe2203sp4" version="3.0.25">
                         <filename>freeradius-devel-3.0.25-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="freeradius-help" release="3.oe2203sp4" version="3.0.25">
                         <filename>freeradius-help-3.0.25-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="freeradius-krb5" release="3.oe2203sp4" version="3.0.25">
                         <filename>freeradius-krb5-3.0.25-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="freeradius-ldap" release="3.oe2203sp4" version="3.0.25">
                         <filename>freeradius-ldap-3.0.25-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="freeradius-mysql" release="3.oe2203sp4" version="3.0.25">
                         <filename>freeradius-mysql-3.0.25-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="freeradius-perl" release="3.oe2203sp4" version="3.0.25">
                         <filename>freeradius-perl-3.0.25-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="freeradius-postgresql" release="3.oe2203sp4" version="3.0.25">
                         <filename>freeradius-postgresql-3.0.25-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="freeradius-sqlite" release="3.oe2203sp4" version="3.0.25">
                         <filename>freeradius-sqlite-3.0.25-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="freeradius-utils" release="3.oe2203sp4" version="3.0.25">
                         <filename>freeradius-utils-3.0.25-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-freeradius" release="3.oe2203sp4" version="3.0.25">
                         <filename>python3-freeradius-3.0.25-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freeradius" release="3.oe2203sp4" version="3.0.25">
                         <filename>freeradius-3.0.25-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freeradius-debuginfo" release="3.oe2203sp4" version="3.0.25">
                         <filename>freeradius-debuginfo-3.0.25-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freeradius-debugsource" release="3.oe2203sp4" version="3.0.25">
                         <filename>freeradius-debugsource-3.0.25-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freeradius-devel" release="3.oe2203sp4" version="3.0.25">
                         <filename>freeradius-devel-3.0.25-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freeradius-help" release="3.oe2203sp4" version="3.0.25">
                         <filename>freeradius-help-3.0.25-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freeradius-krb5" release="3.oe2203sp4" version="3.0.25">
                         <filename>freeradius-krb5-3.0.25-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freeradius-ldap" release="3.oe2203sp4" version="3.0.25">
                         <filename>freeradius-ldap-3.0.25-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freeradius-mysql" release="3.oe2203sp4" version="3.0.25">
                         <filename>freeradius-mysql-3.0.25-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freeradius-perl" release="3.oe2203sp4" version="3.0.25">
                         <filename>freeradius-perl-3.0.25-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freeradius-postgresql" release="3.oe2203sp4" version="3.0.25">
                         <filename>freeradius-postgresql-3.0.25-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freeradius-sqlite" release="3.oe2203sp4" version="3.0.25">
                         <filename>freeradius-sqlite-3.0.25-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freeradius-utils" release="3.oe2203sp4" version="3.0.25">
                         <filename>freeradius-utils-3.0.25-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-freeradius" release="3.oe2203sp4" version="3.0.25">
                         <filename>python3-freeradius-3.0.25-3.oe2203sp4.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-SP4</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 epoch="1" arch="aarch64" name="openssl" release="8.oe2203sp4" version="1.1.1wa">
                         <filename>openssl-1.1.1wa-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="openssl-debuginfo" release="8.oe2203sp4" version="1.1.1wa">
                         <filename>openssl-debuginfo-1.1.1wa-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="openssl-debugsource" release="8.oe2203sp4" version="1.1.1wa">
                         <filename>openssl-debugsource-1.1.1wa-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="openssl-devel" release="8.oe2203sp4" version="1.1.1wa">
                         <filename>openssl-devel-1.1.1wa-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="openssl-libs" release="8.oe2203sp4" version="1.1.1wa">
                         <filename>openssl-libs-1.1.1wa-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="openssl-perl" release="8.oe2203sp4" version="1.1.1wa">
                         <filename>openssl-perl-1.1.1wa-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="openssl-help" release="8.oe2203sp4" version="1.1.1wa">
                         <filename>openssl-help-1.1.1wa-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl" release="8.oe2203sp4" version="1.1.1wa">
                         <filename>openssl-1.1.1wa-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl-debuginfo" release="8.oe2203sp4" version="1.1.1wa">
                         <filename>openssl-debuginfo-1.1.1wa-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl-debugsource" release="8.oe2203sp4" version="1.1.1wa">
                         <filename>openssl-debugsource-1.1.1wa-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl-devel" release="8.oe2203sp4" version="1.1.1wa">
                         <filename>openssl-devel-1.1.1wa-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl-libs" release="8.oe2203sp4" version="1.1.1wa">
                         <filename>openssl-libs-1.1.1wa-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl-perl" release="8.oe2203sp4" version="1.1.1wa">
                         <filename>openssl-perl-1.1.1wa-8.oe2203sp4.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-SP4</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.oe2203sp4" version="1.27.4">
                         <filename>libbson-1.27.4-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libbson-devel" release="1.oe2203sp4" version="1.27.4">
                         <filename>libbson-devel-1.27.4-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mongo-c-driver" release="1.oe2203sp4" version="1.27.4">
                         <filename>mongo-c-driver-1.27.4-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mongo-c-driver-debuginfo" release="1.oe2203sp4" version="1.27.4">
                         <filename>mongo-c-driver-debuginfo-1.27.4-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mongo-c-driver-debugsource" release="1.oe2203sp4" version="1.27.4">
                         <filename>mongo-c-driver-debugsource-1.27.4-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mongo-c-driver-devel" release="1.oe2203sp4" version="1.27.4">
                         <filename>mongo-c-driver-devel-1.27.4-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mongo-c-driver-help" release="1.oe2203sp4" version="1.27.4">
                         <filename>mongo-c-driver-help-1.27.4-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libbson" release="1.oe2203sp4" version="1.27.4">
                         <filename>libbson-1.27.4-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libbson-devel" release="1.oe2203sp4" version="1.27.4">
                         <filename>libbson-devel-1.27.4-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mongo-c-driver" release="1.oe2203sp4" version="1.27.4">
                         <filename>mongo-c-driver-1.27.4-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mongo-c-driver-debuginfo" release="1.oe2203sp4" version="1.27.4">
                         <filename>mongo-c-driver-debuginfo-1.27.4-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mongo-c-driver-debugsource" release="1.oe2203sp4" version="1.27.4">
                         <filename>mongo-c-driver-debugsource-1.27.4-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mongo-c-driver-devel" release="1.oe2203sp4" version="1.27.4">
                         <filename>mongo-c-driver-devel-1.27.4-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mongo-c-driver-help" release="1.oe2203sp4" version="1.27.4">
                         <filename>mongo-c-driver-help-1.27.4-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1884</id>
          <title>An update for mysql is now available for openEuler-22.03-LTS-SP4</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.oe2203sp4" version="8.0.38">
                         <filename>mysql-8.0.38-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-common" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-common-8.0.38-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-config" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-config-8.0.38-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-debuginfo" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-debuginfo-8.0.38-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-debugsource" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-debugsource-8.0.38-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-devel" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-devel-8.0.38-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-errmsg" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-errmsg-8.0.38-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-help" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-help-8.0.38-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-libs" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-libs-8.0.38-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-server" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-server-8.0.38-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-test" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-test-8.0.38-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-8.0.38-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-common" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-common-8.0.38-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-config" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-config-8.0.38-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-debuginfo" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-debuginfo-8.0.38-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-debugsource" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-debugsource-8.0.38-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-devel" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-devel-8.0.38-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-errmsg" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-errmsg-8.0.38-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-help" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-help-8.0.38-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-libs" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-libs-8.0.38-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-server" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-server-8.0.38-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-test" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-test-8.0.38-1.oe2203sp4.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-SP4</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.oe2203sp4" version="2.5.5">
                         <filename>openvpn-2.5.5-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openvpn-debuginfo" release="4.oe2203sp4" version="2.5.5">
                         <filename>openvpn-debuginfo-2.5.5-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openvpn-debugsource" release="4.oe2203sp4" version="2.5.5">
                         <filename>openvpn-debugsource-2.5.5-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openvpn-devel" release="4.oe2203sp4" version="2.5.5">
                         <filename>openvpn-devel-2.5.5-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="openvpn-help" release="4.oe2203sp4" version="2.5.5">
                         <filename>openvpn-help-2.5.5-4.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openvpn" release="4.oe2203sp4" version="2.5.5">
                         <filename>openvpn-2.5.5-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openvpn-debuginfo" release="4.oe2203sp4" version="2.5.5">
                         <filename>openvpn-debuginfo-2.5.5-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openvpn-debugsource" release="4.oe2203sp4" version="2.5.5">
                         <filename>openvpn-debugsource-2.5.5-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openvpn-devel" release="4.oe2203sp4" version="2.5.5">
                         <filename>openvpn-devel-2.5.5-4.oe2203sp4.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-SP4</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.oe2203sp4" version="2.24.33">
                         <filename>gtk2-2.24.33-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gtk2-debuginfo" release="9.oe2203sp4" version="2.24.33">
                         <filename>gtk2-debuginfo-2.24.33-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gtk2-debugsource" release="9.oe2203sp4" version="2.24.33">
                         <filename>gtk2-debugsource-2.24.33-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gtk2-devel" release="9.oe2203sp4" version="2.24.33">
                         <filename>gtk2-devel-2.24.33-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gtk2-help" release="9.oe2203sp4" version="2.24.33">
                         <filename>gtk2-help-2.24.33-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gtk2-immodule-xim" release="9.oe2203sp4" version="2.24.33">
                         <filename>gtk2-immodule-xim-2.24.33-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gtk2" release="9.oe2203sp4" version="2.24.33">
                         <filename>gtk2-2.24.33-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gtk2-debuginfo" release="9.oe2203sp4" version="2.24.33">
                         <filename>gtk2-debuginfo-2.24.33-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gtk2-debugsource" release="9.oe2203sp4" version="2.24.33">
                         <filename>gtk2-debugsource-2.24.33-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gtk2-devel" release="9.oe2203sp4" version="2.24.33">
                         <filename>gtk2-devel-2.24.33-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gtk2-help" release="9.oe2203sp4" version="2.24.33">
                         <filename>gtk2-help-2.24.33-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gtk2-immodule-xim" release="9.oe2203sp4" version="2.24.33">
                         <filename>gtk2-immodule-xim-2.24.33-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1888</id>
          <title>An update for python-zipp is now available for openEuler-22.03-LTS-SP4</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.oe2203sp4" version="3.7.0">
                         <filename>python-zipp-help-3.7.0-3.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-zipp" release="3.oe2203sp4" version="3.7.0">
                         <filename>python3-zipp-3.7.0-3.oe2203sp4.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-SP4</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.oe2203sp4" version="1.27.4">
                         <filename>libbson-1.27.4-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libbson-devel" release="1.oe2203sp4" version="1.27.4">
                         <filename>libbson-devel-1.27.4-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mongo-c-driver" release="1.oe2203sp4" version="1.27.4">
                         <filename>mongo-c-driver-1.27.4-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mongo-c-driver-debuginfo" release="1.oe2203sp4" version="1.27.4">
                         <filename>mongo-c-driver-debuginfo-1.27.4-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mongo-c-driver-debugsource" release="1.oe2203sp4" version="1.27.4">
                         <filename>mongo-c-driver-debugsource-1.27.4-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mongo-c-driver-devel" release="1.oe2203sp4" version="1.27.4">
                         <filename>mongo-c-driver-devel-1.27.4-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mongo-c-driver-help" release="1.oe2203sp4" version="1.27.4">
                         <filename>mongo-c-driver-help-1.27.4-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libbson" release="1.oe2203sp4" version="1.27.4">
                         <filename>libbson-1.27.4-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libbson-devel" release="1.oe2203sp4" version="1.27.4">
                         <filename>libbson-devel-1.27.4-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mongo-c-driver" release="1.oe2203sp4" version="1.27.4">
                         <filename>mongo-c-driver-1.27.4-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mongo-c-driver-debuginfo" release="1.oe2203sp4" version="1.27.4">
                         <filename>mongo-c-driver-debuginfo-1.27.4-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mongo-c-driver-debugsource" release="1.oe2203sp4" version="1.27.4">
                         <filename>mongo-c-driver-debugsource-1.27.4-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mongo-c-driver-devel" release="1.oe2203sp4" version="1.27.4">
                         <filename>mongo-c-driver-devel-1.27.4-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mongo-c-driver-help" release="1.oe2203sp4" version="1.27.4">
                         <filename>mongo-c-driver-help-1.27.4-1.oe2203sp4.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-SP4</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.oe2203sp4" version="3.24.30">
                         <filename>gtk-update-icon-cache-3.24.30-11.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gtk3" release="11.oe2203sp4" version="3.24.30">
                         <filename>gtk3-3.24.30-11.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gtk3-debuginfo" release="11.oe2203sp4" version="3.24.30">
                         <filename>gtk3-debuginfo-3.24.30-11.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gtk3-debugsource" release="11.oe2203sp4" version="3.24.30">
                         <filename>gtk3-debugsource-3.24.30-11.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gtk3-devel" release="11.oe2203sp4" version="3.24.30">
                         <filename>gtk3-devel-3.24.30-11.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gtk3-help" release="11.oe2203sp4" version="3.24.30">
                         <filename>gtk3-help-3.24.30-11.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gtk3-immodule-xim" release="11.oe2203sp4" version="3.24.30">
                         <filename>gtk3-immodule-xim-3.24.30-11.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gtk-update-icon-cache" release="11.oe2203sp4" version="3.24.30">
                         <filename>gtk-update-icon-cache-3.24.30-11.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gtk3" release="11.oe2203sp4" version="3.24.30">
                         <filename>gtk3-3.24.30-11.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gtk3-debuginfo" release="11.oe2203sp4" version="3.24.30">
                         <filename>gtk3-debuginfo-3.24.30-11.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gtk3-debugsource" release="11.oe2203sp4" version="3.24.30">
                         <filename>gtk3-debugsource-3.24.30-11.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gtk3-devel" release="11.oe2203sp4" version="3.24.30">
                         <filename>gtk3-devel-3.24.30-11.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gtk3-help" release="11.oe2203sp4" version="3.24.30">
                         <filename>gtk3-help-3.24.30-11.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gtk3-immodule-xim" release="11.oe2203sp4" version="3.24.30">
                         <filename>gtk3-immodule-xim-3.24.30-11.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1898</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-07-26"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48814" id="CVE-2022-48814" title="CVE-2022-48814" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36939" id="CVE-2024-36939" title="CVE-2024-36939" 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>
          </references>
          <description>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: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: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)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="bpftool" release="220.0.0.119.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-220.0.0.119.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="220.0.0.119.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-220.0.0.119.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="220.0.0.119.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-220.0.0.119.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="220.0.0.119.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-220.0.0.119.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="220.0.0.119.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-220.0.0.119.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="220.0.0.119.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-220.0.0.119.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="220.0.0.119.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-220.0.0.119.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="220.0.0.119.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-220.0.0.119.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="220.0.0.119.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-220.0.0.119.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="220.0.0.119.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-220.0.0.119.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="220.0.0.119.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-220.0.0.119.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="220.0.0.119.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-220.0.0.119.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="220.0.0.119.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-220.0.0.119.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="220.0.0.119.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-220.0.0.119.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="220.0.0.119.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-220.0.0.119.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="220.0.0.119.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-220.0.0.119.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="220.0.0.119.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-220.0.0.119.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="220.0.0.119.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-220.0.0.119.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="220.0.0.119.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-220.0.0.119.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="220.0.0.119.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-220.0.0.119.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="220.0.0.119.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-220.0.0.119.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="220.0.0.119.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-220.0.0.119.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="220.0.0.119.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-220.0.0.119.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="220.0.0.119.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-220.0.0.119.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="220.0.0.119.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-220.0.0.119.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="220.0.0.119.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-220.0.0.119.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="220.0.0.119.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-220.0.0.119.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="220.0.0.119.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-220.0.0.119.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="220.0.0.119.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-220.0.0.119.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="220.0.0.119.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-220.0.0.119.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1908</id>
          <title>An update for openjdk-11 is now available for openEuler-22.03-LTS-SP4</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.oe2203sp4" version="11.0.24.8">
                         <filename>java-11-openjdk-11.0.24.8-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-debuginfo" release="0.oe2203sp4" version="11.0.24.8">
                         <filename>java-11-openjdk-debuginfo-11.0.24.8-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-debugsource" release="0.oe2203sp4" version="11.0.24.8">
                         <filename>java-11-openjdk-debugsource-11.0.24.8-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-demo" release="0.oe2203sp4" version="11.0.24.8">
                         <filename>java-11-openjdk-demo-11.0.24.8-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-demo-slowdebug" release="0.oe2203sp4" version="11.0.24.8">
                         <filename>java-11-openjdk-demo-slowdebug-11.0.24.8-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-devel" release="0.oe2203sp4" version="11.0.24.8">
                         <filename>java-11-openjdk-devel-11.0.24.8-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-devel-slowdebug" release="0.oe2203sp4" version="11.0.24.8">
                         <filename>java-11-openjdk-devel-slowdebug-11.0.24.8-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-headless" release="0.oe2203sp4" version="11.0.24.8">
                         <filename>java-11-openjdk-headless-11.0.24.8-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-headless-slowdebug" release="0.oe2203sp4" version="11.0.24.8">
                         <filename>java-11-openjdk-headless-slowdebug-11.0.24.8-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-javadoc" release="0.oe2203sp4" version="11.0.24.8">
                         <filename>java-11-openjdk-javadoc-11.0.24.8-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-javadoc-zip" release="0.oe2203sp4" version="11.0.24.8">
                         <filename>java-11-openjdk-javadoc-zip-11.0.24.8-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-jmods" release="0.oe2203sp4" version="11.0.24.8">
                         <filename>java-11-openjdk-jmods-11.0.24.8-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-jmods-slowdebug" release="0.oe2203sp4" version="11.0.24.8">
                         <filename>java-11-openjdk-jmods-slowdebug-11.0.24.8-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-slowdebug" release="0.oe2203sp4" version="11.0.24.8">
                         <filename>java-11-openjdk-slowdebug-11.0.24.8-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-src" release="0.oe2203sp4" version="11.0.24.8">
                         <filename>java-11-openjdk-src-11.0.24.8-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-src-slowdebug" release="0.oe2203sp4" version="11.0.24.8">
                         <filename>java-11-openjdk-src-slowdebug-11.0.24.8-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk" release="0.oe2203sp4" version="11.0.24.8">
                         <filename>java-11-openjdk-11.0.24.8-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-debuginfo" release="0.oe2203sp4" version="11.0.24.8">
                         <filename>java-11-openjdk-debuginfo-11.0.24.8-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-debugsource" release="0.oe2203sp4" version="11.0.24.8">
                         <filename>java-11-openjdk-debugsource-11.0.24.8-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-demo" release="0.oe2203sp4" version="11.0.24.8">
                         <filename>java-11-openjdk-demo-11.0.24.8-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-demo-slowdebug" release="0.oe2203sp4" version="11.0.24.8">
                         <filename>java-11-openjdk-demo-slowdebug-11.0.24.8-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-devel" release="0.oe2203sp4" version="11.0.24.8">
                         <filename>java-11-openjdk-devel-11.0.24.8-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-devel-slowdebug" release="0.oe2203sp4" version="11.0.24.8">
                         <filename>java-11-openjdk-devel-slowdebug-11.0.24.8-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-headless" release="0.oe2203sp4" version="11.0.24.8">
                         <filename>java-11-openjdk-headless-11.0.24.8-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-headless-slowdebug" release="0.oe2203sp4" version="11.0.24.8">
                         <filename>java-11-openjdk-headless-slowdebug-11.0.24.8-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-javadoc" release="0.oe2203sp4" version="11.0.24.8">
                         <filename>java-11-openjdk-javadoc-11.0.24.8-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-javadoc-zip" release="0.oe2203sp4" version="11.0.24.8">
                         <filename>java-11-openjdk-javadoc-zip-11.0.24.8-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-jmods" release="0.oe2203sp4" version="11.0.24.8">
                         <filename>java-11-openjdk-jmods-11.0.24.8-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-jmods-slowdebug" release="0.oe2203sp4" version="11.0.24.8">
                         <filename>java-11-openjdk-jmods-slowdebug-11.0.24.8-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-slowdebug" release="0.oe2203sp4" version="11.0.24.8">
                         <filename>java-11-openjdk-slowdebug-11.0.24.8-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-src" release="0.oe2203sp4" version="11.0.24.8">
                         <filename>java-11-openjdk-src-11.0.24.8-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-src-slowdebug" release="0.oe2203sp4" version="11.0.24.8">
                         <filename>java-11-openjdk-src-slowdebug-11.0.24.8-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1911</id>
          <title>An update for assimp is now available for openEuler-22.03-LTS-SP4</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.oe2203sp4" version="5.2.4">
                         <filename>assimp-5.2.4-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="assimp-debuginfo" release="2.oe2203sp4" version="5.2.4">
                         <filename>assimp-debuginfo-5.2.4-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="assimp-debugsource" release="2.oe2203sp4" version="5.2.4">
                         <filename>assimp-debugsource-5.2.4-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="assimp-devel" release="2.oe2203sp4" version="5.2.4">
                         <filename>assimp-devel-5.2.4-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="assimp-help" release="2.oe2203sp4" version="5.2.4">
                         <filename>assimp-help-5.2.4-2.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-assimp" release="2.oe2203sp4" version="5.2.4">
                         <filename>python3-assimp-5.2.4-2.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="assimp" release="2.oe2203sp4" version="5.2.4">
                         <filename>assimp-5.2.4-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="assimp-debuginfo" release="2.oe2203sp4" version="5.2.4">
                         <filename>assimp-debuginfo-5.2.4-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="assimp-debugsource" release="2.oe2203sp4" version="5.2.4">
                         <filename>assimp-debugsource-5.2.4-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="assimp-devel" release="2.oe2203sp4" version="5.2.4">
                         <filename>assimp-devel-5.2.4-2.oe2203sp4.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-SP4</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.oe2203sp4" version="202011">
                         <filename>edk2-debuginfo-202011-19.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="edk2-debugsource" release="19.oe2203sp4" version="202011">
                         <filename>edk2-debugsource-202011-19.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="edk2-devel" release="19.oe2203sp4" version="202011">
                         <filename>edk2-devel-202011-19.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-aarch64" release="19.oe2203sp4" version="202011">
                         <filename>edk2-aarch64-202011-19.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-help" release="19.oe2203sp4" version="202011">
                         <filename>edk2-help-202011-19.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-ovmf" release="19.oe2203sp4" version="202011">
                         <filename>edk2-ovmf-202011-19.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-edk2-devel" release="19.oe2203sp4" version="202011">
                         <filename>python3-edk2-devel-202011-19.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-debuginfo" release="19.oe2203sp4" version="202011">
                         <filename>edk2-debuginfo-202011-19.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-debugsource" release="19.oe2203sp4" version="202011">
                         <filename>edk2-debugsource-202011-19.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-devel" release="19.oe2203sp4" version="202011">
                         <filename>edk2-devel-202011-19.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1917</id>
          <title>An update for avro is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-08-02"></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.oe2203sp4" version="1.10.2">
                         <filename>avro-1.10.2-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avro" release="5.oe2203sp4" version="1.10.2">
                         <filename>avro-1.10.2-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1921</id>
          <title>An update for mysql is now available for openEuler-22.03-LTS-SP4</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-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.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-errmsg" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-errmsg-8.0.38-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-8.0.38-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-server" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-server-8.0.38-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-common" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-common-8.0.38-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-config" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-config-8.0.38-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-help" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-help-8.0.38-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-devel" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-devel-8.0.38-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-debuginfo" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-debuginfo-8.0.38-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-libs" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-libs-8.0.38-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-test" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-test-8.0.38-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-debugsource" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-debugsource-8.0.38-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-help" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-help-8.0.38-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-test" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-test-8.0.38-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-debuginfo" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-debuginfo-8.0.38-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-server" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-server-8.0.38-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-debugsource" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-debugsource-8.0.38-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-errmsg" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-errmsg-8.0.38-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-config" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-config-8.0.38-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-common" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-common-8.0.38-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-8.0.38-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-libs" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-libs-8.0.38-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-devel" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-devel-8.0.38-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1925</id>
          <title>An update for botan2 is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-08-02"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-34702" id="CVE-2024-34702" title="CVE-2024-34702" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-34703" id="CVE-2024-34703" title="CVE-2024-34703" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39312" id="CVE-2024-39312" title="CVE-2024-39312" type="cve"></reference>
          </references>
          <description>Botan is a C++ cryptography library. X.509 certificates can identify elliptic curves using either an object identifier or using explicit encoding of the parameters.  Prior to 3.5.0 and 2.19.5, checking name constraints in X.509 certificates is quadratic in the number of names and name constraints. An attacker who presented a certificate chain which contained a very large number of names in the SubjectAlternativeName, signed by a CA certificate which contained a large number of name constraints, could cause a denial of service. The problem has been addressed in Botan 3.5.0 and a partial backport has also been applied and is included in Botan 2.19.5.(CVE-2024-34702)Botan is a C++ cryptography library. X.509 certificates can identify elliptic curves using either an object identifier or using explicit encoding of the parameters. Prior to versions 3.3.0 and 2.19.4, an attacker could present an ECDSA X.509 certificate using explicit encoding where the parameters are very large. The proof of concept used a 16Kbit prime for this purpose. When parsing, the parameter is checked to be prime, causing excessive computation. This was patched in 2.19.4 and 3.3.0 to allow the prime parameter of the elliptic curve to be at most 521 bits. No known workarounds are available. Note that support for explicit encoding of elliptic curve parameters is deprecated in Botan.(CVE-2024-34703)Botan is a C++ cryptography library. X.509 certificates can identify elliptic curves using either an object identifier or using explicit encoding of the parameters. A bug in the parsing of name constraint extensions in X.509 certificates meant that if the extension included both permitted subtrees and excluded subtrees, only the permitted subtree would be checked. If a certificate included a name which was permitted by the permitted subtree but also excluded by excluded subtree, it would be accepted. Fixed in versions 3.5.0 and 2.19.5.(CVE-2024-39312)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="python3-botan2" release="3.oe2203sp4" version="2.19.3">
                         <filename>python3-botan2-2.19.3-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="botan2" release="3.oe2203sp4" version="2.19.3">
                         <filename>botan2-2.19.3-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="botan2-debugsource" release="3.oe2203sp4" version="2.19.3">
                         <filename>botan2-debugsource-2.19.3-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="botan2-devel" release="3.oe2203sp4" version="2.19.3">
                         <filename>botan2-devel-2.19.3-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="botan2-debuginfo" release="3.oe2203sp4" version="2.19.3">
                         <filename>botan2-debuginfo-2.19.3-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="botan2-doc" release="3.oe2203sp4" version="2.19.3">
                         <filename>botan2-doc-2.19.3-3.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="botan2-debugsource" release="3.oe2203sp4" version="2.19.3">
                         <filename>botan2-debugsource-2.19.3-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="botan2-debuginfo" release="3.oe2203sp4" version="2.19.3">
                         <filename>botan2-debuginfo-2.19.3-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="botan2" release="3.oe2203sp4" version="2.19.3">
                         <filename>botan2-2.19.3-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-botan2" release="3.oe2203sp4" version="2.19.3">
                         <filename>python3-botan2-2.19.3-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="botan2-devel" release="3.oe2203sp4" version="2.19.3">
                         <filename>botan2-devel-2.19.3-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1927</id>
          <title>An update for exim is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-08-02"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3559" id="CVE-2022-3559" title="CVE-2022-3559" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-51766" id="CVE-2023-51766" title="CVE-2023-51766" type="cve"></reference>
          </references>
          <description>A vulnerability was found in Exim and classified as problematic. This issue affects some unknown processing of the component Regex Handler. The manipulation leads to use after free. The name of the patch is 4e9ed49f8f12eb331b29bd5b6dc3693c520fddc2. It is recommended to apply a patch to fix this issue. The identifier VDB-211073 was assigned to this vulnerability.(CVE-2022-3559)Exim before 4.97.1 allows SMTP smuggling in certain PIPELINING/CHUNKING configurations. Remote attackers can use a published exploitation technique to inject e-mail messages with a spoofed MAIL FROM address, allowing bypass of an SPF protection mechanism. This occurs because Exim supports &lt;LF&gt;.&lt;CR&gt;&lt;LF&gt; but some other popular e-mail servers do not.(CVE-2023-51766)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="exim-debugsource" release="3.oe2203sp4" version="4.96">
                         <filename>exim-debugsource-4.96-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="exim" release="3.oe2203sp4" version="4.96">
                         <filename>exim-4.96-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="exim-clamav" release="3.oe2203sp4" version="4.96">
                         <filename>exim-clamav-4.96-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="exim-pgsql" release="3.oe2203sp4" version="4.96">
                         <filename>exim-pgsql-4.96-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="exim-mon" release="3.oe2203sp4" version="4.96">
                         <filename>exim-mon-4.96-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="exim-debuginfo" release="3.oe2203sp4" version="4.96">
                         <filename>exim-debuginfo-4.96-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="exim-mysql" release="3.oe2203sp4" version="4.96">
                         <filename>exim-mysql-4.96-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="exim-greylist" release="3.oe2203sp4" version="4.96">
                         <filename>exim-greylist-4.96-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="exim-debugsource" release="3.oe2203sp4" version="4.96">
                         <filename>exim-debugsource-4.96-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="exim-mysql" release="3.oe2203sp4" version="4.96">
                         <filename>exim-mysql-4.96-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="exim-clamav" release="3.oe2203sp4" version="4.96">
                         <filename>exim-clamav-4.96-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="exim" release="3.oe2203sp4" version="4.96">
                         <filename>exim-4.96-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="exim-pgsql" release="3.oe2203sp4" version="4.96">
                         <filename>exim-pgsql-4.96-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="exim-debuginfo" release="3.oe2203sp4" version="4.96">
                         <filename>exim-debuginfo-4.96-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="exim-mon" release="3.oe2203sp4" version="4.96">
                         <filename>exim-mon-4.96-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="exim-greylist" release="3.oe2203sp4" version="4.96">
                         <filename>exim-greylist-4.96-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1930</id>
          <title>An update for mpv is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-08-02"></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.oe2203sp4" version="0.32.0">
                         <filename>mpv-debuginfo-0.32.0-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mpv" release="3.oe2203sp4" version="0.32.0">
                         <filename>mpv-0.32.0-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mpv-libs-devel" release="3.oe2203sp4" version="0.32.0">
                         <filename>mpv-libs-devel-0.32.0-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mpv-libs" release="3.oe2203sp4" version="0.32.0">
                         <filename>mpv-libs-0.32.0-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mpv-debugsource" release="3.oe2203sp4" version="0.32.0">
                         <filename>mpv-debugsource-0.32.0-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mpv-debugsource" release="3.oe2203sp4" version="0.32.0">
                         <filename>mpv-debugsource-0.32.0-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mpv" release="3.oe2203sp4" version="0.32.0">
                         <filename>mpv-0.32.0-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mpv-libs-devel" release="3.oe2203sp4" version="0.32.0">
                         <filename>mpv-libs-devel-0.32.0-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mpv-libs" release="3.oe2203sp4" version="0.32.0">
                         <filename>mpv-libs-0.32.0-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mpv-debuginfo" release="3.oe2203sp4" version="0.32.0">
                         <filename>mpv-debuginfo-0.32.0-3.oe2203sp4.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-SP4</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.oe2203sp4" version="59.4.0">
                         <filename>python3-setuptools-59.4.0-6.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python-setuptools" release="6.oe2203sp4" version="59.4.0">
                         <filename>python-setuptools-59.4.0-6.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python-setuptools-help" release="6.oe2203sp4" version="59.4.0">
                         <filename>python-setuptools-help-59.4.0-6.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1933</id>
          <title>An update for mysql is now available for openEuler-22.03-LTS-SP4</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-21165" id="CVE-2024-21165" title="CVE-2024-21165" 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: 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: 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.oe2203sp4" version="8.0.38">
                         <filename>mysql-errmsg-8.0.38-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-8.0.38-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-server" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-server-8.0.38-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-common" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-common-8.0.38-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-config" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-config-8.0.38-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-help" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-help-8.0.38-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-devel" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-devel-8.0.38-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-debuginfo" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-debuginfo-8.0.38-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-libs" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-libs-8.0.38-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-test" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-test-8.0.38-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-debugsource" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-debugsource-8.0.38-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-help" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-help-8.0.38-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-test" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-test-8.0.38-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-debuginfo" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-debuginfo-8.0.38-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-server" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-server-8.0.38-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-debugsource" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-debugsource-8.0.38-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-errmsg" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-errmsg-8.0.38-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-config" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-config-8.0.38-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-common" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-common-8.0.38-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-8.0.38-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-libs" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-libs-8.0.38-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-devel" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-devel-8.0.38-1.oe2203sp4.x86_64.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-SP4</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 epoch="1" arch="aarch64" name="java-17-openjdk" release="0.oe2203sp4" version="17.0.12.7">
                         <filename>java-17-openjdk-17.0.12.7-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-17-openjdk-debuginfo" release="0.oe2203sp4" version="17.0.12.7">
                         <filename>java-17-openjdk-debuginfo-17.0.12.7-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-17-openjdk-debugsource" release="0.oe2203sp4" version="17.0.12.7">
                         <filename>java-17-openjdk-debugsource-17.0.12.7-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-17-openjdk-demo" release="0.oe2203sp4" version="17.0.12.7">
                         <filename>java-17-openjdk-demo-17.0.12.7-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-17-openjdk-demo-slowdebug" release="0.oe2203sp4" version="17.0.12.7">
                         <filename>java-17-openjdk-demo-slowdebug-17.0.12.7-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-17-openjdk-devel" release="0.oe2203sp4" version="17.0.12.7">
                         <filename>java-17-openjdk-devel-17.0.12.7-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-17-openjdk-devel-slowdebug" release="0.oe2203sp4" version="17.0.12.7">
                         <filename>java-17-openjdk-devel-slowdebug-17.0.12.7-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-17-openjdk-headless" release="0.oe2203sp4" version="17.0.12.7">
                         <filename>java-17-openjdk-headless-17.0.12.7-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-17-openjdk-headless-slowdebug" release="0.oe2203sp4" version="17.0.12.7">
                         <filename>java-17-openjdk-headless-slowdebug-17.0.12.7-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-17-openjdk-javadoc" release="0.oe2203sp4" version="17.0.12.7">
                         <filename>java-17-openjdk-javadoc-17.0.12.7-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-17-openjdk-javadoc-zip" release="0.oe2203sp4" version="17.0.12.7">
                         <filename>java-17-openjdk-javadoc-zip-17.0.12.7-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-17-openjdk-jmods" release="0.oe2203sp4" version="17.0.12.7">
                         <filename>java-17-openjdk-jmods-17.0.12.7-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-17-openjdk-jmods-slowdebug" release="0.oe2203sp4" version="17.0.12.7">
                         <filename>java-17-openjdk-jmods-slowdebug-17.0.12.7-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-17-openjdk-slowdebug" release="0.oe2203sp4" version="17.0.12.7">
                         <filename>java-17-openjdk-slowdebug-17.0.12.7-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-17-openjdk-src" release="0.oe2203sp4" version="17.0.12.7">
                         <filename>java-17-openjdk-src-17.0.12.7-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-17-openjdk-src-slowdebug" release="0.oe2203sp4" version="17.0.12.7">
                         <filename>java-17-openjdk-src-slowdebug-17.0.12.7-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-17-openjdk" release="0.oe2203sp4" version="17.0.12.7">
                         <filename>java-17-openjdk-17.0.12.7-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-17-openjdk-debuginfo" release="0.oe2203sp4" version="17.0.12.7">
                         <filename>java-17-openjdk-debuginfo-17.0.12.7-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-17-openjdk-debugsource" release="0.oe2203sp4" version="17.0.12.7">
                         <filename>java-17-openjdk-debugsource-17.0.12.7-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-17-openjdk-demo" release="0.oe2203sp4" version="17.0.12.7">
                         <filename>java-17-openjdk-demo-17.0.12.7-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-17-openjdk-demo-slowdebug" release="0.oe2203sp4" version="17.0.12.7">
                         <filename>java-17-openjdk-demo-slowdebug-17.0.12.7-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-17-openjdk-devel" release="0.oe2203sp4" version="17.0.12.7">
                         <filename>java-17-openjdk-devel-17.0.12.7-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-17-openjdk-devel-slowdebug" release="0.oe2203sp4" version="17.0.12.7">
                         <filename>java-17-openjdk-devel-slowdebug-17.0.12.7-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-17-openjdk-headless" release="0.oe2203sp4" version="17.0.12.7">
                         <filename>java-17-openjdk-headless-17.0.12.7-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-17-openjdk-headless-slowdebug" release="0.oe2203sp4" version="17.0.12.7">
                         <filename>java-17-openjdk-headless-slowdebug-17.0.12.7-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-17-openjdk-javadoc" release="0.oe2203sp4" version="17.0.12.7">
                         <filename>java-17-openjdk-javadoc-17.0.12.7-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-17-openjdk-javadoc-zip" release="0.oe2203sp4" version="17.0.12.7">
                         <filename>java-17-openjdk-javadoc-zip-17.0.12.7-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-17-openjdk-jmods" release="0.oe2203sp4" version="17.0.12.7">
                         <filename>java-17-openjdk-jmods-17.0.12.7-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-17-openjdk-jmods-slowdebug" release="0.oe2203sp4" version="17.0.12.7">
                         <filename>java-17-openjdk-jmods-slowdebug-17.0.12.7-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-17-openjdk-slowdebug" release="0.oe2203sp4" version="17.0.12.7">
                         <filename>java-17-openjdk-slowdebug-17.0.12.7-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-17-openjdk-src" release="0.oe2203sp4" version="17.0.12.7">
                         <filename>java-17-openjdk-src-17.0.12.7-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-17-openjdk-src-slowdebug" release="0.oe2203sp4" version="17.0.12.7">
                         <filename>java-17-openjdk-src-slowdebug-17.0.12.7-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1956</id>
          <title>An update for busybox is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-08-09"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-42363" id="CVE-2023-42363" title="CVE-2023-42363" type="cve"></reference>
          </references>
          <description>A use-after-free vulnerability was discovered in xasprintf function in xfuncs_printf.c:344 in BusyBox v.1.36.1.(CVE-2023-42363)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="busybox" release="22.oe2203sp4" version="1.34.1">
                         <filename>busybox-1.34.1-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="busybox-debuginfo" release="22.oe2203sp4" version="1.34.1">
                         <filename>busybox-debuginfo-1.34.1-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="busybox-debugsource" release="22.oe2203sp4" version="1.34.1">
                         <filename>busybox-debugsource-1.34.1-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="busybox-help" release="22.oe2203sp4" version="1.34.1">
                         <filename>busybox-help-1.34.1-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="busybox-petitboot" release="22.oe2203sp4" version="1.34.1">
                         <filename>busybox-petitboot-1.34.1-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="busybox" release="22.oe2203sp4" version="1.34.1">
                         <filename>busybox-1.34.1-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="busybox-debuginfo" release="22.oe2203sp4" version="1.34.1">
                         <filename>busybox-debuginfo-1.34.1-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="busybox-debugsource" release="22.oe2203sp4" version="1.34.1">
                         <filename>busybox-debugsource-1.34.1-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="busybox-help" release="22.oe2203sp4" version="1.34.1">
                         <filename>busybox-help-1.34.1-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="busybox-petitboot" release="22.oe2203sp4" version="1.34.1">
                         <filename>busybox-petitboot-1.34.1-22.oe2203sp4.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-SP4</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 epoch="1" arch="aarch64" name="java-1.8.0-openjdk" release="0.oe2203sp4" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-1.8.0.422.b05-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-accessibility" release="0.oe2203sp4" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-accessibility-1.8.0.422.b05-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-accessibility-slowdebug" release="0.oe2203sp4" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.422.b05-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-debuginfo" release="0.oe2203sp4" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-debuginfo-1.8.0.422.b05-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-debugsource" release="0.oe2203sp4" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-debugsource-1.8.0.422.b05-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-demo" release="0.oe2203sp4" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-demo-1.8.0.422.b05-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-demo-slowdebug" release="0.oe2203sp4" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-demo-slowdebug-1.8.0.422.b05-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-devel" release="0.oe2203sp4" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-devel-1.8.0.422.b05-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-devel-slowdebug" release="0.oe2203sp4" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-devel-slowdebug-1.8.0.422.b05-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-headless" release="0.oe2203sp4" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-headless-1.8.0.422.b05-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-headless-slowdebug" release="0.oe2203sp4" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-headless-slowdebug-1.8.0.422.b05-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-openjfx" release="0.oe2203sp4" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-openjfx-1.8.0.422.b05-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-openjfx-devel" release="0.oe2203sp4" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-openjfx-devel-1.8.0.422.b05-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-openjfx-devel-slowdebug" release="0.oe2203sp4" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.422.b05-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-openjfx-slowdebug" release="0.oe2203sp4" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.422.b05-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-slowdebug" release="0.oe2203sp4" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-slowdebug-1.8.0.422.b05-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-src" release="0.oe2203sp4" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-src-1.8.0.422.b05-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-src-slowdebug" release="0.oe2203sp4" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-src-slowdebug-1.8.0.422.b05-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="java-1.8.0-openjdk-javadoc" release="0.oe2203sp4" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-javadoc-1.8.0.422.b05-0.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="java-1.8.0-openjdk-javadoc-zip" release="0.oe2203sp4" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-javadoc-zip-1.8.0.422.b05-0.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk" release="0.oe2203sp4" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-1.8.0.422.b05-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-accessibility" release="0.oe2203sp4" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-accessibility-1.8.0.422.b05-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-accessibility-slowdebug" release="0.oe2203sp4" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.422.b05-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-debuginfo" release="0.oe2203sp4" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-debuginfo-1.8.0.422.b05-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-debugsource" release="0.oe2203sp4" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-debugsource-1.8.0.422.b05-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-demo" release="0.oe2203sp4" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-demo-1.8.0.422.b05-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-demo-slowdebug" release="0.oe2203sp4" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-demo-slowdebug-1.8.0.422.b05-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-devel" release="0.oe2203sp4" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-devel-1.8.0.422.b05-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-devel-slowdebug" release="0.oe2203sp4" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-devel-slowdebug-1.8.0.422.b05-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-headless" release="0.oe2203sp4" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-headless-1.8.0.422.b05-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-headless-slowdebug" release="0.oe2203sp4" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-headless-slowdebug-1.8.0.422.b05-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-openjfx" release="0.oe2203sp4" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-openjfx-1.8.0.422.b05-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-openjfx-devel" release="0.oe2203sp4" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-openjfx-devel-1.8.0.422.b05-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-openjfx-devel-slowdebug" release="0.oe2203sp4" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.422.b05-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-openjfx-slowdebug" release="0.oe2203sp4" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.422.b05-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-slowdebug" release="0.oe2203sp4" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-slowdebug-1.8.0.422.b05-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-src" release="0.oe2203sp4" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-src-1.8.0.422.b05-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-src-slowdebug" release="0.oe2203sp4" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-src-slowdebug-1.8.0.422.b05-0.oe2203sp4.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-SP4</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 epoch="2" arch="aarch64" name="docker-engine" release="340.oe2203sp4" version="18.09.0">
                         <filename>docker-engine-18.09.0-340.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="docker-engine-debuginfo" release="340.oe2203sp4" version="18.09.0">
                         <filename>docker-engine-debuginfo-18.09.0-340.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="docker-engine-debugsource" release="340.oe2203sp4" version="18.09.0">
                         <filename>docker-engine-debugsource-18.09.0-340.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="docker-engine" release="340.oe2203sp4" version="18.09.0">
                         <filename>docker-engine-18.09.0-340.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="docker-engine-debuginfo" release="340.oe2203sp4" version="18.09.0">
                         <filename>docker-engine-debuginfo-18.09.0-340.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="docker-engine-debugsource" release="340.oe2203sp4" version="18.09.0">
                         <filename>docker-engine-debugsource-18.09.0-340.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1961</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-08-09"></issued>
          <references>
               <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-52887" id="CVE-2023-52887" title="CVE-2023-52887" 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-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-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-40967" id="CVE-2024-40967" title="CVE-2024-40967" 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-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-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-41044" id="CVE-2024-41044" title="CVE-2024-41044" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41055" id="CVE-2024-41055" title="CVE-2024-41055" 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-41064" id="CVE-2024-41064" title="CVE-2024-41064" 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-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-41073" id="CVE-2024-41073" title="CVE-2024-41073" 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-41081" id="CVE-2024-41081" title="CVE-2024-41081" 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-41089" id="CVE-2024-41089" title="CVE-2024-41089" 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-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-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-42124" id="CVE-2024-42124" title="CVE-2024-42124" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42137" id="CVE-2024-42137" title="CVE-2024-42137" 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>
          </references>
          <description>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: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: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/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: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: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: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: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: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: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:mm: prevent derefencing NULL ptr in pfn_section_valid()Commit 5ec8e8ea8b77 (&#34;mm/sparsemem: fix race in accessingmemory_section-&gt;usage&#34;) changed pfn_section_valid() to add a READ_ONCE()call around &#34;ms-&gt;usage&#34; to fix a race with section_deactivate() wherems-&gt;usage can be cleared.  The READ_ONCE() call, by itself, is not enoughto prevent NULL pointer dereference.  We need to check its value beforedereferencing it.(CVE-2024-41055)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: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: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: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: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: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: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: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: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: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: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: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: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:Bluetooth: qca: Fix BT enable failure again for QCA6390 after warm rebootCommit 272970be3dab (&#34;Bluetooth: hci_qca: Fix driver shutdown on closedserdev&#34;) will cause below regression issue:BT can&#39;t be enabled after below steps:cold boot -&gt; enable BT -&gt; disable BT -&gt; warm reboot -&gt; BT enable failureif property enable-gpios is not configured within DT|ACPI for QCA6390.The commit is to fix a use-after-free issue within qca_serdev_shutdown()by adding condition to avoid the serdev is flushed or wrote after closedbut also introduces this regression issue regarding above steps since theVSC is not sent to reset controller during warm reboot.Fixed by sending the VSC to reset controller within qca_serdev_shutdown()once BT was ever enabled, and the use-after-free issue is also fixed bythis change since the serdev is still opened before it is flushed or wrote.Verified by the reported machine Dell XPS 13 9310 laptop over below twokernel commits:commit e00fc2700a3f (&#34;Bluetooth: btusb: Fix triggering coredumpimplementation for QCA&#34;) of bluetooth-next tree.commit b23d98d46d28 (&#34;Bluetooth: btusb: Fix triggering coredumpimplementation for QCA&#34;) of linus mainline tree.(CVE-2024-42137)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)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="bpftool" release="222.0.0.121.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-222.0.0.121.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="222.0.0.121.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-222.0.0.121.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="222.0.0.121.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-222.0.0.121.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="222.0.0.121.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-222.0.0.121.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="222.0.0.121.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-222.0.0.121.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="222.0.0.121.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-222.0.0.121.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="222.0.0.121.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-222.0.0.121.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="222.0.0.121.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-222.0.0.121.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="222.0.0.121.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-222.0.0.121.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="222.0.0.121.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-222.0.0.121.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="222.0.0.121.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-222.0.0.121.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="222.0.0.121.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-222.0.0.121.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="222.0.0.121.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-222.0.0.121.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="222.0.0.121.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-222.0.0.121.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="222.0.0.121.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-222.0.0.121.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="222.0.0.121.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-222.0.0.121.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="222.0.0.121.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-222.0.0.121.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="222.0.0.121.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-222.0.0.121.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="222.0.0.121.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-222.0.0.121.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="222.0.0.121.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-222.0.0.121.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="222.0.0.121.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-222.0.0.121.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="222.0.0.121.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-222.0.0.121.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="222.0.0.121.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-222.0.0.121.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="222.0.0.121.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-222.0.0.121.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="222.0.0.121.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-222.0.0.121.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="222.0.0.121.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-222.0.0.121.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="222.0.0.121.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-222.0.0.121.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="222.0.0.121.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-222.0.0.121.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="222.0.0.121.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-222.0.0.121.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="222.0.0.121.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-222.0.0.121.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1967</id>
          <title>An update for qpdf is now available for openEuler-22.03-LTS-SP4</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.oe2203sp4" version="8.4.2">
                         <filename>qpdf-8.4.2-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qpdf-debuginfo" release="5.oe2203sp4" version="8.4.2">
                         <filename>qpdf-debuginfo-8.4.2-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qpdf-debugsource" release="5.oe2203sp4" version="8.4.2">
                         <filename>qpdf-debugsource-8.4.2-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qpdf-devel" release="5.oe2203sp4" version="8.4.2">
                         <filename>qpdf-devel-8.4.2-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="qpdf-help" release="5.oe2203sp4" version="8.4.2">
                         <filename>qpdf-help-8.4.2-5.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qpdf" release="5.oe2203sp4" version="8.4.2">
                         <filename>qpdf-8.4.2-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qpdf-debuginfo" release="5.oe2203sp4" version="8.4.2">
                         <filename>qpdf-debuginfo-8.4.2-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qpdf-debugsource" release="5.oe2203sp4" version="8.4.2">
                         <filename>qpdf-debugsource-8.4.2-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qpdf-devel" release="5.oe2203sp4" version="8.4.2">
                         <filename>qpdf-devel-8.4.2-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1970</id>
          <title>An update for bind is now available for openEuler-22.03-LTS-SP4</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.oe2203sp4" version="9.16.23">
                         <filename>bind-9.16.23-23.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-chroot" release="23.oe2203sp4" version="9.16.23">
                         <filename>bind-chroot-9.16.23-23.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-debuginfo" release="23.oe2203sp4" version="9.16.23">
                         <filename>bind-debuginfo-9.16.23-23.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-debugsource" release="23.oe2203sp4" version="9.16.23">
                         <filename>bind-debugsource-9.16.23-23.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-devel" release="23.oe2203sp4" version="9.16.23">
                         <filename>bind-devel-9.16.23-23.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-dnssec-utils" release="23.oe2203sp4" version="9.16.23">
                         <filename>bind-dnssec-utils-9.16.23-23.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-libs" release="23.oe2203sp4" version="9.16.23">
                         <filename>bind-libs-9.16.23-23.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-pkcs11" release="23.oe2203sp4" version="9.16.23">
                         <filename>bind-pkcs11-9.16.23-23.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-pkcs11-devel" release="23.oe2203sp4" version="9.16.23">
                         <filename>bind-pkcs11-devel-9.16.23-23.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-pkcs11-libs" release="23.oe2203sp4" version="9.16.23">
                         <filename>bind-pkcs11-libs-9.16.23-23.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-pkcs11-utils" release="23.oe2203sp4" version="9.16.23">
                         <filename>bind-pkcs11-utils-9.16.23-23.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-utils" release="23.oe2203sp4" version="9.16.23">
                         <filename>bind-utils-9.16.23-23.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="noarch" name="bind-dnssec-doc" release="23.oe2203sp4" version="9.16.23">
                         <filename>bind-dnssec-doc-9.16.23-23.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="32" arch="noarch" name="bind-license" release="23.oe2203sp4" version="9.16.23">
                         <filename>bind-license-9.16.23-23.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="32" arch="noarch" name="python3-bind" release="23.oe2203sp4" version="9.16.23">
                         <filename>python3-bind-9.16.23-23.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind" release="23.oe2203sp4" version="9.16.23">
                         <filename>bind-9.16.23-23.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-chroot" release="23.oe2203sp4" version="9.16.23">
                         <filename>bind-chroot-9.16.23-23.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-debuginfo" release="23.oe2203sp4" version="9.16.23">
                         <filename>bind-debuginfo-9.16.23-23.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-debugsource" release="23.oe2203sp4" version="9.16.23">
                         <filename>bind-debugsource-9.16.23-23.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-devel" release="23.oe2203sp4" version="9.16.23">
                         <filename>bind-devel-9.16.23-23.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-dnssec-utils" release="23.oe2203sp4" version="9.16.23">
                         <filename>bind-dnssec-utils-9.16.23-23.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-libs" release="23.oe2203sp4" version="9.16.23">
                         <filename>bind-libs-9.16.23-23.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-pkcs11" release="23.oe2203sp4" version="9.16.23">
                         <filename>bind-pkcs11-9.16.23-23.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-pkcs11-devel" release="23.oe2203sp4" version="9.16.23">
                         <filename>bind-pkcs11-devel-9.16.23-23.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-pkcs11-libs" release="23.oe2203sp4" version="9.16.23">
                         <filename>bind-pkcs11-libs-9.16.23-23.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-pkcs11-utils" release="23.oe2203sp4" version="9.16.23">
                         <filename>bind-pkcs11-utils-9.16.23-23.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-utils" release="23.oe2203sp4" version="9.16.23">
                         <filename>bind-utils-9.16.23-23.oe2203sp4.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-SP4</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.oe2203sp4" version="0.4.32">
                         <filename>orc-0.4.32-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="orc-compiler" release="3.oe2203sp4" version="0.4.32">
                         <filename>orc-compiler-0.4.32-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="orc-debuginfo" release="3.oe2203sp4" version="0.4.32">
                         <filename>orc-debuginfo-0.4.32-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="orc-debugsource" release="3.oe2203sp4" version="0.4.32">
                         <filename>orc-debugsource-0.4.32-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="orc-devel" release="3.oe2203sp4" version="0.4.32">
                         <filename>orc-devel-0.4.32-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="orc-help" release="3.oe2203sp4" version="0.4.32">
                         <filename>orc-help-0.4.32-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="orc" release="3.oe2203sp4" version="0.4.32">
                         <filename>orc-0.4.32-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="orc-compiler" release="3.oe2203sp4" version="0.4.32">
                         <filename>orc-compiler-0.4.32-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="orc-debuginfo" release="3.oe2203sp4" version="0.4.32">
                         <filename>orc-debuginfo-0.4.32-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="orc-debugsource" release="3.oe2203sp4" version="0.4.32">
                         <filename>orc-debugsource-0.4.32-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="orc-devel" release="3.oe2203sp4" version="0.4.32">
                         <filename>orc-devel-0.4.32-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="orc-help" release="3.oe2203sp4" version="0.4.32">
                         <filename>orc-help-0.4.32-3.oe2203sp4.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-SP4</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 epoch="2" arch="aarch64" name="vim-X11" release="24.oe2203sp4" version="9.0">
                         <filename>vim-X11-9.0-24.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-common" release="24.oe2203sp4" version="9.0">
                         <filename>vim-common-9.0-24.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-debuginfo" release="24.oe2203sp4" version="9.0">
                         <filename>vim-debuginfo-9.0-24.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-debugsource" release="24.oe2203sp4" version="9.0">
                         <filename>vim-debugsource-9.0-24.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-enhanced" release="24.oe2203sp4" version="9.0">
                         <filename>vim-enhanced-9.0-24.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-minimal" release="24.oe2203sp4" version="9.0">
                         <filename>vim-minimal-9.0-24.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="noarch" name="vim-filesystem" release="24.oe2203sp4" version="9.0">
                         <filename>vim-filesystem-9.0-24.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-X11" release="24.oe2203sp4" version="9.0">
                         <filename>vim-X11-9.0-24.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-common" release="24.oe2203sp4" version="9.0">
                         <filename>vim-common-9.0-24.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-debuginfo" release="24.oe2203sp4" version="9.0">
                         <filename>vim-debuginfo-9.0-24.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-debugsource" release="24.oe2203sp4" version="9.0">
                         <filename>vim-debugsource-9.0-24.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-enhanced" release="24.oe2203sp4" version="9.0">
                         <filename>vim-enhanced-9.0-24.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-minimal" release="24.oe2203sp4" version="9.0">
                         <filename>vim-minimal-9.0-24.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1994</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP4</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-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-40956" id="CVE-2024-40956" title="CVE-2024-40956" 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-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-42126" id="CVE-2024-42126" title="CVE-2024-42126" 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-42158" id="CVE-2024-42158" title="CVE-2024-42158" 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: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: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: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: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: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: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:s390/pkey: Use kfree_sensitive() to fix Coccinelle warningsReplace memzero_explicit() and kfree() with kfree_sensitive() to fixwarnings reported by Coccinelle:WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1506)WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1643)WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1770)(CVE-2024-42158)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="bpftool" release="223.0.0.122.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-223.0.0.122.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="223.0.0.122.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-223.0.0.122.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="223.0.0.122.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-223.0.0.122.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="223.0.0.122.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-223.0.0.122.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="223.0.0.122.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-223.0.0.122.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="223.0.0.122.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-223.0.0.122.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="223.0.0.122.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-223.0.0.122.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="223.0.0.122.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-223.0.0.122.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="223.0.0.122.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-223.0.0.122.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="223.0.0.122.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-223.0.0.122.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="223.0.0.122.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-223.0.0.122.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="223.0.0.122.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-223.0.0.122.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="223.0.0.122.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-223.0.0.122.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="223.0.0.122.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-223.0.0.122.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="223.0.0.122.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-223.0.0.122.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="223.0.0.122.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-223.0.0.122.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="223.0.0.122.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-223.0.0.122.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="223.0.0.122.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-223.0.0.122.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="223.0.0.122.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-223.0.0.122.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="223.0.0.122.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-223.0.0.122.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="223.0.0.122.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-223.0.0.122.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="223.0.0.122.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-223.0.0.122.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="223.0.0.122.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-223.0.0.122.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="223.0.0.122.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-223.0.0.122.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="223.0.0.122.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-223.0.0.122.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="223.0.0.122.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-223.0.0.122.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="223.0.0.122.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-223.0.0.122.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="223.0.0.122.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-223.0.0.122.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="223.0.0.122.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-223.0.0.122.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="223.0.0.122.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-223.0.0.122.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2001</id>
          <title>An update for texlive-base is now available for openEuler-22.03-LTS-SP4</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.oe2203sp4" version="20180414">
                         <filename>texlive-afm2pl-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-aleph" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-aleph-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-autosp" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-autosp-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-axodraw2" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-axodraw2-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-base" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-base-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-base-debuginfo" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-base-debuginfo-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-base-debugsource" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-base-debugsource-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-bibtex" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-bibtex-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-bibtex8" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-bibtex8-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-bibtexu" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-bibtexu-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-chktex" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-chktex-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-cjkutils" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-cjkutils-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-ctie" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-ctie-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-cweb" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-cweb-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-detex" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-detex-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-dtl" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-dtl-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-dvi2tty" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-dvi2tty-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-dvicopy" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-dvicopy-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-dvidvi" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-dvidvi-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-dviljk" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-dviljk-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-dvipdfmx" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-dvipdfmx-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-dvipng" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-dvipng-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-dvipos" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-dvipos-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-dvips" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-dvips-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-dvisvgm" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-dvisvgm-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-fontware" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-fontware-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-gregoriotex" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-gregoriotex-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-gsftopk" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-gsftopk-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-kpathsea" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-kpathsea-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-lacheck" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-lacheck-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-lcdftypetools" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-lcdftypetools-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-lib" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-lib-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-lib-devel" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-lib-devel-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-luatex" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-luatex-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-m-tx" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-m-tx-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-makeindex" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-makeindex-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-metafont" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-metafont-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-metapost" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-metapost-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-mflua" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-mflua-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-mfware" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-mfware-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-musixtnt" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-musixtnt-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-omegaware" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-omegaware-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-patgen" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-patgen-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-pdftex" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-pdftex-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-pdftools" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-pdftools-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-pmx" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-pmx-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-ps2pk" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-ps2pk-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-pstools" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-pstools-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-ptex" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-ptex-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-seetexk" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-seetexk-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-synctex" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-synctex-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-tex" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-tex-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-tex4ht" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-tex4ht-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-texware" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-texware-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-tie" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-tie-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-ttfutils" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-ttfutils-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-uptex" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-uptex-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-velthuis" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-velthuis-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-vlna" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-vlna-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-web" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-web-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-xdvi" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-xdvi-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-xetex" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-xetex-20180414-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-a2ping" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-a2ping-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-accfonts" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-accfonts-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-adhocfilelist" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-adhocfilelist-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-amstex" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-amstex-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-arara" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-arara-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-authorindex" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-authorindex-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-bib2gls" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-bib2gls-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-bibexport" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-bibexport-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-bundledoc" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-bundledoc-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-cachepic" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-cachepic-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-checkcites" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-checkcites-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-checklistings" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-checklistings-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-context" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-context-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-convbkmk" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-convbkmk-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-crossrefware" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-crossrefware-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-cslatex" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-cslatex-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-csplain" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-csplain-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-ctan-o-mat" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-ctan-o-mat-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-ctanify" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-ctanify-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="texlive-ctanupload" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-ctanupload-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-cyrillic" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-cyrillic-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-de-macro" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-de-macro-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-diadia" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-diadia-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-dosepsbin" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-dosepsbin-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-dtxgen" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-dtxgen-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-dviasm" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-dviasm-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-dviinfox" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-dviinfox-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-ebong" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-ebong-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-eplain" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-eplain-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-epspdf" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-epspdf-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-epstopdf" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-epstopdf-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="texlive-exceltex" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-exceltex-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-fig4latex" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-fig4latex-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-findhyph" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-findhyph-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-fontinst" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-fontinst-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-fontools" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-fontools-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-fragmaster" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-fragmaster-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-getmap" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-getmap-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-glossaries" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-glossaries-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-glyphlist" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-glyphlist-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-installfont" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-installfont-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-jadetex" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-jadetex-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-jfmutil" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-jfmutil-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-kotex-utils" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-kotex-utils-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-l3build" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-l3build-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-latex" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-latex-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-latex-git-log" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-latex-git-log-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-latex-papersize" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-latex-papersize-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-latex2man" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-latex2man-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-latex2nemeth" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-latex2nemeth-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-latexdiff" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-latexdiff-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-latexfileversion" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-latexfileversion-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="texlive-latexindent" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-latexindent-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-latexpand" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-latexpand-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-lilyglyphs" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-lilyglyphs-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-listbib" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-listbib-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-listings-ext" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-listings-ext-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-lollipop" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-lollipop-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-ltxfileinfo" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-ltxfileinfo-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-ltximg" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-ltximg-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-lua2dox" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-lua2dox-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-luaotfload" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-luaotfload-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-lwarp" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-lwarp-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-lyluatex" release="38.oe2203sp4" version="svn47584">
                         <filename>texlive-lyluatex-svn47584-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-make4ht" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-make4ht-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-makedtx" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-makedtx-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-match_parens" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-match_parens-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-mathspic" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-mathspic-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-mex" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-mex-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-mf2pt1" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-mf2pt1-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-mkgrkindex" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-mkgrkindex-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-mkjobtexmf" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-mkjobtexmf-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-mkpic" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-mkpic-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-mltex" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-mltex-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-mptopdf" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-mptopdf-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-multibibliography" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-multibibliography-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-musixtex" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-musixtex-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-oberdiek" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-oberdiek-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-pax" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-pax-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-pdfbook2" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-pdfbook2-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-pdfcrop" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-pdfcrop-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-pdfjam" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-pdfjam-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-pdflatexpicscale" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-pdflatexpicscale-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-pdfxup" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-pdfxup-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-pedigree-perl" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-pedigree-perl-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-perltex" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-perltex-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-petri-nets" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-petri-nets-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-pfarrei" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-pfarrei-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-pkfix" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-pkfix-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-pkfix-helper" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-pkfix-helper-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-pmxchords" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-pmxchords-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-pst-pdf" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-pst-pdf-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-pst2pdf" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-pst2pdf-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-ptex-fontmaps" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-ptex-fontmaps-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-ptex2pdf" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-ptex2pdf-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-purifyeps" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-purifyeps-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-pygmentex" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-pygmentex-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-pythontex" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-pythontex-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-rubik" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-rubik-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-splitindex" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-splitindex-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-srcredact" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-srcredact-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-sty2dtx" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-sty2dtx-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-svn-multi" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-svn-multi-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-tetex" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-tetex-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-tex4ebook" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-tex4ebook-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-texconfig" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-texconfig-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-texcount" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-texcount-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-texdef" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-texdef-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-texdiff" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-texdiff-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-texdirflatten" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-texdirflatten-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-texdoc" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-texdoc-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-texdoctk" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-texdoctk-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-texfot" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-texfot-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-texlive-en" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-texlive-en-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-texlive-scripts" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-texlive-scripts-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-texlive.infra" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-texlive.infra-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-texliveonfly" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-texliveonfly-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-texloganalyser" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-texloganalyser-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-texosquery" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-texosquery-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-texsis" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-texsis-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-thumbpdf" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-thumbpdf-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-tpic2pdftex" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-tpic2pdftex-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-typeoutfileinfo" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-typeoutfileinfo-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-ulqda" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-ulqda-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-urlbst" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-urlbst-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-vpe" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-vpe-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-wordcount" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-wordcount-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-xmltex" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-xmltex-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-yplan" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-yplan-20180414-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-afm2pl" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-afm2pl-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-aleph" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-aleph-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-autosp" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-autosp-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-axodraw2" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-axodraw2-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-base" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-base-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-base-debuginfo" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-base-debuginfo-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-base-debugsource" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-base-debugsource-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-bibtex" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-bibtex-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-bibtex8" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-bibtex8-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-bibtexu" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-bibtexu-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-chktex" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-chktex-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-cjkutils" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-cjkutils-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-ctie" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-ctie-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-cweb" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-cweb-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-detex" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-detex-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-dtl" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-dtl-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-dvi2tty" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-dvi2tty-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-dvicopy" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-dvicopy-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-dvidvi" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-dvidvi-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-dviljk" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-dviljk-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-dvipdfmx" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-dvipdfmx-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-dvipng" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-dvipng-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-dvipos" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-dvipos-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-dvips" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-dvips-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-dvisvgm" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-dvisvgm-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-fontware" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-fontware-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-gregoriotex" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-gregoriotex-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-gsftopk" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-gsftopk-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-kpathsea" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-kpathsea-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-lacheck" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-lacheck-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-lcdftypetools" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-lcdftypetools-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-lib" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-lib-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-lib-devel" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-lib-devel-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-luatex" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-luatex-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-m-tx" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-m-tx-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-makeindex" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-makeindex-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-metafont" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-metafont-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-metapost" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-metapost-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-mflua" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-mflua-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-mfware" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-mfware-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-musixtnt" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-musixtnt-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-omegaware" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-omegaware-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-patgen" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-patgen-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-pdftex" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-pdftex-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-pdftools" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-pdftools-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-pmx" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-pmx-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-ps2pk" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-ps2pk-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-pstools" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-pstools-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-ptex" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-ptex-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-seetexk" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-seetexk-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-synctex" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-synctex-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-tex" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-tex-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-tex4ht" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-tex4ht-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-texware" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-texware-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-tie" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-tie-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-ttfutils" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-ttfutils-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-uptex" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-uptex-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-velthuis" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-velthuis-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-vlna" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-vlna-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-web" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-web-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-xdvi" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-xdvi-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-xetex" release="38.oe2203sp4" version="20180414">
                         <filename>texlive-xetex-20180414-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2007</id>
          <title>An update for mysql is now available for openEuler-22.03-LTS-SP4</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.oe2203sp4" version="8.0.38">
                         <filename>mysql-8.0.38-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-common" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-common-8.0.38-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-config" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-config-8.0.38-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-debuginfo" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-debuginfo-8.0.38-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-debugsource" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-debugsource-8.0.38-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-devel" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-devel-8.0.38-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-errmsg" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-errmsg-8.0.38-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-help" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-help-8.0.38-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-libs" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-libs-8.0.38-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-server" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-server-8.0.38-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-test" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-test-8.0.38-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-8.0.38-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-common" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-common-8.0.38-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-config" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-config-8.0.38-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-debuginfo" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-debuginfo-8.0.38-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-debugsource" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-debugsource-8.0.38-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-devel" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-devel-8.0.38-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-errmsg" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-errmsg-8.0.38-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-help" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-help-8.0.38-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-libs" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-libs-8.0.38-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-server" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-server-8.0.38-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-test" release="1.oe2203sp4" version="8.0.38">
                         <filename>mysql-test-8.0.38-1.oe2203sp4.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-SP4</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 epoch="1" arch="aarch64" name="dovecot" release="6.oe2203sp4" version="2.3.15">
                         <filename>dovecot-2.3.15-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="dovecot-debuginfo" release="6.oe2203sp4" version="2.3.15">
                         <filename>dovecot-debuginfo-2.3.15-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="dovecot-debugsource" release="6.oe2203sp4" version="2.3.15">
                         <filename>dovecot-debugsource-2.3.15-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="dovecot-devel" release="6.oe2203sp4" version="2.3.15">
                         <filename>dovecot-devel-2.3.15-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="dovecot-help" release="6.oe2203sp4" version="2.3.15">
                         <filename>dovecot-help-2.3.15-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="dovecot" release="6.oe2203sp4" version="2.3.15">
                         <filename>dovecot-2.3.15-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="dovecot-debuginfo" release="6.oe2203sp4" version="2.3.15">
                         <filename>dovecot-debuginfo-2.3.15-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="dovecot-debugsource" release="6.oe2203sp4" version="2.3.15">
                         <filename>dovecot-debugsource-2.3.15-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="dovecot-devel" release="6.oe2203sp4" version="2.3.15">
                         <filename>dovecot-devel-2.3.15-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="dovecot-help" release="6.oe2203sp4" version="2.3.15">
                         <filename>dovecot-help-2.3.15-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2017</id>
          <title>An update for bind is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-08-23"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0760" id="CVE-2024-0760" title="CVE-2024-0760" type="cve"></reference>
          </references>
          <description>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.oe2203sp4" version="9.16.23">
                         <filename>bind-9.16.23-23.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-chroot" release="23.oe2203sp4" version="9.16.23">
                         <filename>bind-chroot-9.16.23-23.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-debuginfo" release="23.oe2203sp4" version="9.16.23">
                         <filename>bind-debuginfo-9.16.23-23.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-debugsource" release="23.oe2203sp4" version="9.16.23">
                         <filename>bind-debugsource-9.16.23-23.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-devel" release="23.oe2203sp4" version="9.16.23">
                         <filename>bind-devel-9.16.23-23.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-dnssec-utils" release="23.oe2203sp4" version="9.16.23">
                         <filename>bind-dnssec-utils-9.16.23-23.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-libs" release="23.oe2203sp4" version="9.16.23">
                         <filename>bind-libs-9.16.23-23.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-pkcs11" release="23.oe2203sp4" version="9.16.23">
                         <filename>bind-pkcs11-9.16.23-23.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-pkcs11-devel" release="23.oe2203sp4" version="9.16.23">
                         <filename>bind-pkcs11-devel-9.16.23-23.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-pkcs11-libs" release="23.oe2203sp4" version="9.16.23">
                         <filename>bind-pkcs11-libs-9.16.23-23.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-pkcs11-utils" release="23.oe2203sp4" version="9.16.23">
                         <filename>bind-pkcs11-utils-9.16.23-23.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-utils" release="23.oe2203sp4" version="9.16.23">
                         <filename>bind-utils-9.16.23-23.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="noarch" name="bind-dnssec-doc" release="23.oe2203sp4" version="9.16.23">
                         <filename>bind-dnssec-doc-9.16.23-23.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="32" arch="noarch" name="bind-license" release="23.oe2203sp4" version="9.16.23">
                         <filename>bind-license-9.16.23-23.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="32" arch="noarch" name="python3-bind" release="23.oe2203sp4" version="9.16.23">
                         <filename>python3-bind-9.16.23-23.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind" release="23.oe2203sp4" version="9.16.23">
                         <filename>bind-9.16.23-23.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-chroot" release="23.oe2203sp4" version="9.16.23">
                         <filename>bind-chroot-9.16.23-23.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-debuginfo" release="23.oe2203sp4" version="9.16.23">
                         <filename>bind-debuginfo-9.16.23-23.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-debugsource" release="23.oe2203sp4" version="9.16.23">
                         <filename>bind-debugsource-9.16.23-23.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-devel" release="23.oe2203sp4" version="9.16.23">
                         <filename>bind-devel-9.16.23-23.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-dnssec-utils" release="23.oe2203sp4" version="9.16.23">
                         <filename>bind-dnssec-utils-9.16.23-23.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-libs" release="23.oe2203sp4" version="9.16.23">
                         <filename>bind-libs-9.16.23-23.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-pkcs11" release="23.oe2203sp4" version="9.16.23">
                         <filename>bind-pkcs11-9.16.23-23.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-pkcs11-devel" release="23.oe2203sp4" version="9.16.23">
                         <filename>bind-pkcs11-devel-9.16.23-23.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-pkcs11-libs" release="23.oe2203sp4" version="9.16.23">
                         <filename>bind-pkcs11-libs-9.16.23-23.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-pkcs11-utils" release="23.oe2203sp4" version="9.16.23">
                         <filename>bind-pkcs11-utils-9.16.23-23.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-utils" release="23.oe2203sp4" version="9.16.23">
                         <filename>bind-utils-9.16.23-23.oe2203sp4.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-SP4</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="13.oe2203sp4" version="1.13.2">
                         <filename>python3-unbound-1.13.2-13.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="unbound" release="13.oe2203sp4" version="1.13.2">
                         <filename>unbound-1.13.2-13.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="unbound-anchor" release="13.oe2203sp4" version="1.13.2">
                         <filename>unbound-anchor-1.13.2-13.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="unbound-debuginfo" release="13.oe2203sp4" version="1.13.2">
                         <filename>unbound-debuginfo-1.13.2-13.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="unbound-debugsource" release="13.oe2203sp4" version="1.13.2">
                         <filename>unbound-debugsource-1.13.2-13.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="unbound-devel" release="13.oe2203sp4" version="1.13.2">
                         <filename>unbound-devel-1.13.2-13.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="unbound-help" release="13.oe2203sp4" version="1.13.2">
                         <filename>unbound-help-1.13.2-13.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="unbound-libs" release="13.oe2203sp4" version="1.13.2">
                         <filename>unbound-libs-1.13.2-13.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-unbound" release="13.oe2203sp4" version="1.13.2">
                         <filename>python3-unbound-1.13.2-13.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="unbound" release="13.oe2203sp4" version="1.13.2">
                         <filename>unbound-1.13.2-13.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="unbound-anchor" release="13.oe2203sp4" version="1.13.2">
                         <filename>unbound-anchor-1.13.2-13.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="unbound-debuginfo" release="13.oe2203sp4" version="1.13.2">
                         <filename>unbound-debuginfo-1.13.2-13.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="unbound-debugsource" release="13.oe2203sp4" version="1.13.2">
                         <filename>unbound-debugsource-1.13.2-13.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="unbound-devel" release="13.oe2203sp4" version="1.13.2">
                         <filename>unbound-devel-1.13.2-13.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="unbound-help" release="13.oe2203sp4" version="1.13.2">
                         <filename>unbound-help-1.13.2-13.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="unbound-libs" release="13.oe2203sp4" version="1.13.2">
                         <filename>unbound-libs-1.13.2-13.oe2203sp4.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-SP4</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 epoch="2" arch="aarch64" name="vim-X11" release="25.oe2203sp4" version="9.0">
                         <filename>vim-X11-9.0-25.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-common" release="25.oe2203sp4" version="9.0">
                         <filename>vim-common-9.0-25.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-debuginfo" release="25.oe2203sp4" version="9.0">
                         <filename>vim-debuginfo-9.0-25.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-debugsource" release="25.oe2203sp4" version="9.0">
                         <filename>vim-debugsource-9.0-25.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-enhanced" release="25.oe2203sp4" version="9.0">
                         <filename>vim-enhanced-9.0-25.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-minimal" release="25.oe2203sp4" version="9.0">
                         <filename>vim-minimal-9.0-25.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="noarch" name="vim-filesystem" release="25.oe2203sp4" version="9.0">
                         <filename>vim-filesystem-9.0-25.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-X11" release="25.oe2203sp4" version="9.0">
                         <filename>vim-X11-9.0-25.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-common" release="25.oe2203sp4" version="9.0">
                         <filename>vim-common-9.0-25.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-debuginfo" release="25.oe2203sp4" version="9.0">
                         <filename>vim-debuginfo-9.0-25.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-debugsource" release="25.oe2203sp4" version="9.0">
                         <filename>vim-debugsource-9.0-25.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-enhanced" release="25.oe2203sp4" version="9.0">
                         <filename>vim-enhanced-9.0-25.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-minimal" release="25.oe2203sp4" version="9.0">
                         <filename>vim-minimal-9.0-25.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2027</id>
          <title>An update for qemu is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-08-23"></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.oe2203sp4" version="6.2.0">
                         <filename>qemu-6.2.0-97.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-curl" release="97.oe2203sp4" version="6.2.0">
                         <filename>qemu-block-curl-6.2.0-97.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-iscsi" release="97.oe2203sp4" version="6.2.0">
                         <filename>qemu-block-iscsi-6.2.0-97.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-rbd" release="97.oe2203sp4" version="6.2.0">
                         <filename>qemu-block-rbd-6.2.0-97.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-ssh" release="97.oe2203sp4" version="6.2.0">
                         <filename>qemu-block-ssh-6.2.0-97.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-debuginfo" release="97.oe2203sp4" version="6.2.0">
                         <filename>qemu-debuginfo-6.2.0-97.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-debugsource" release="97.oe2203sp4" version="6.2.0">
                         <filename>qemu-debugsource-6.2.0-97.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-guest-agent" release="97.oe2203sp4" version="6.2.0">
                         <filename>qemu-guest-agent-6.2.0-97.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-hw-usb-host" release="97.oe2203sp4" version="6.2.0">
                         <filename>qemu-hw-usb-host-6.2.0-97.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-img" release="97.oe2203sp4" version="6.2.0">
                         <filename>qemu-img-6.2.0-97.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-aarch64" release="97.oe2203sp4" version="6.2.0">
                         <filename>qemu-system-aarch64-6.2.0-97.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-arm" release="97.oe2203sp4" version="6.2.0">
                         <filename>qemu-system-arm-6.2.0-97.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-riscv" release="97.oe2203sp4" version="6.2.0">
                         <filename>qemu-system-riscv-6.2.0-97.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-x86_64" release="97.oe2203sp4" version="6.2.0">
                         <filename>qemu-system-x86_64-6.2.0-97.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="noarch" name="qemu-help" release="97.oe2203sp4" version="6.2.0">
                         <filename>qemu-help-6.2.0-97.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu" release="97.oe2203sp4" version="6.2.0">
                         <filename>qemu-6.2.0-97.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-curl" release="97.oe2203sp4" version="6.2.0">
                         <filename>qemu-block-curl-6.2.0-97.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-iscsi" release="97.oe2203sp4" version="6.2.0">
                         <filename>qemu-block-iscsi-6.2.0-97.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-rbd" release="97.oe2203sp4" version="6.2.0">
                         <filename>qemu-block-rbd-6.2.0-97.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-ssh" release="97.oe2203sp4" version="6.2.0">
                         <filename>qemu-block-ssh-6.2.0-97.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-debuginfo" release="97.oe2203sp4" version="6.2.0">
                         <filename>qemu-debuginfo-6.2.0-97.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-debugsource" release="97.oe2203sp4" version="6.2.0">
                         <filename>qemu-debugsource-6.2.0-97.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-guest-agent" release="97.oe2203sp4" version="6.2.0">
                         <filename>qemu-guest-agent-6.2.0-97.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-hw-usb-host" release="97.oe2203sp4" version="6.2.0">
                         <filename>qemu-hw-usb-host-6.2.0-97.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-img" release="97.oe2203sp4" version="6.2.0">
                         <filename>qemu-img-6.2.0-97.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-seabios" release="97.oe2203sp4" version="6.2.0">
                         <filename>qemu-seabios-6.2.0-97.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-aarch64" release="97.oe2203sp4" version="6.2.0">
                         <filename>qemu-system-aarch64-6.2.0-97.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-arm" release="97.oe2203sp4" version="6.2.0">
                         <filename>qemu-system-arm-6.2.0-97.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-riscv" release="97.oe2203sp4" version="6.2.0">
                         <filename>qemu-system-riscv-6.2.0-97.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-x86_64" release="97.oe2203sp4" version="6.2.0">
                         <filename>qemu-system-x86_64-6.2.0-97.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2028</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-08-23"></issued>
          <references>
               <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-34777" id="CVE-2024-34777" title="CVE-2024-34777" 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-38565" id="CVE-2024-38565" title="CVE-2024-38565" 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-39476" id="CVE-2024-39476" title="CVE-2024-39476" 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-40945" id="CVE-2024-40945" title="CVE-2024-40945" 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-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-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: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: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: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: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: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: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: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: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: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: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: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="bpftool" release="224.0.0.123.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-224.0.0.123.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="224.0.0.123.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-224.0.0.123.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="224.0.0.123.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-224.0.0.123.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="224.0.0.123.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-224.0.0.123.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="224.0.0.123.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-224.0.0.123.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="224.0.0.123.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-224.0.0.123.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="224.0.0.123.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-224.0.0.123.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="224.0.0.123.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-224.0.0.123.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="224.0.0.123.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-224.0.0.123.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="224.0.0.123.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-224.0.0.123.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="224.0.0.123.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-224.0.0.123.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="224.0.0.123.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-224.0.0.123.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="224.0.0.123.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-224.0.0.123.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="224.0.0.123.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-224.0.0.123.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="224.0.0.123.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-224.0.0.123.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="224.0.0.123.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-224.0.0.123.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="224.0.0.123.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-224.0.0.123.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="224.0.0.123.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-224.0.0.123.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="224.0.0.123.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-224.0.0.123.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="224.0.0.123.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-224.0.0.123.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="224.0.0.123.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-224.0.0.123.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="224.0.0.123.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-224.0.0.123.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="224.0.0.123.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-224.0.0.123.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="224.0.0.123.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-224.0.0.123.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="224.0.0.123.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-224.0.0.123.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="224.0.0.123.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-224.0.0.123.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="224.0.0.123.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-224.0.0.123.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="224.0.0.123.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-224.0.0.123.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="224.0.0.123.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-224.0.0.123.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="224.0.0.123.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-224.0.0.123.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2033</id>
          <title>An update for rubygem-rack is now available for openEuler-22.03-LTS-SP4</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="5.oe2203sp4" version="2.2.3.1">
                         <filename>rubygem-rack-2.2.3.1-5.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="rubygem-rack-help" release="5.oe2203sp4" version="2.2.3.1">
                         <filename>rubygem-rack-help-2.2.3.1-5.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2036</id>
          <title>An update for python-django is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2024-08-23"></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.oe2203sp4" version="4.2.15">
                         <filename>python-django-help-4.2.15-1.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-Django" release="1.oe2203sp4" version="4.2.15">
                         <filename>python3-Django-4.2.15-1.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2037</id>
          <title>An update for python-urllib3 is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-08-23"></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.oe2203sp4" version="1.26.12">
                         <filename>python3-urllib3-1.26.12-7.oe2203sp4.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-SP4</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.oe2203sp4" version="3.0.3">
                         <filename>ruby-3.0.3-137.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ruby-debuginfo" release="137.oe2203sp4" version="3.0.3">
                         <filename>ruby-debuginfo-3.0.3-137.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ruby-debugsource" release="137.oe2203sp4" version="3.0.3">
                         <filename>ruby-debugsource-3.0.3-137.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ruby-devel" release="137.oe2203sp4" version="3.0.3">
                         <filename>ruby-devel-3.0.3-137.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-bigdecimal" release="137.oe2203sp4" version="3.0.0">
                         <filename>rubygem-bigdecimal-3.0.0-137.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-io-console" release="137.oe2203sp4" version="0.5.7">
                         <filename>rubygem-io-console-0.5.7-137.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-json" release="137.oe2203sp4" version="2.5.1">
                         <filename>rubygem-json-2.5.1-137.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-openssl" release="137.oe2203sp4" version="2.2.1">
                         <filename>rubygem-openssl-2.2.1-137.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-psych" release="137.oe2203sp4" version="3.3.2">
                         <filename>rubygem-psych-3.3.2-137.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="ruby-help" release="137.oe2203sp4" version="3.0.3">
                         <filename>ruby-help-3.0.3-137.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="ruby-irb" release="137.oe2203sp4" version="3.0.3">
                         <filename>ruby-irb-3.0.3-137.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-bundler" release="137.oe2203sp4" version="2.2.32">
                         <filename>rubygem-bundler-2.2.32-137.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-did_you_mean" release="137.oe2203sp4" version="1.5.0">
                         <filename>rubygem-did_you_mean-1.5.0-137.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-minitest" release="137.oe2203sp4" version="5.14.2">
                         <filename>rubygem-minitest-5.14.2-137.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rake" release="137.oe2203sp4" version="13.0.3">
                         <filename>rubygem-rake-13.0.3-137.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rbs" release="137.oe2203sp4" version="1.4.0">
                         <filename>rubygem-rbs-1.4.0-137.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rdoc" release="137.oe2203sp4" version="6.3.3">
                         <filename>rubygem-rdoc-6.3.3-137.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rexml" release="137.oe2203sp4" version="3.2.5">
                         <filename>rubygem-rexml-3.2.5-137.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rss" release="137.oe2203sp4" version="0.2.9">
                         <filename>rubygem-rss-0.2.9-137.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-test-unit" release="137.oe2203sp4" version="3.3.7">
                         <filename>rubygem-test-unit-3.3.7-137.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-typeprof" release="137.oe2203sp4" version="0.15.2">
                         <filename>rubygem-typeprof-0.15.2-137.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygems" release="137.oe2203sp4" version="3.2.32">
                         <filename>rubygems-3.2.32-137.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygems-devel" release="137.oe2203sp4" version="3.2.32">
                         <filename>rubygems-devel-3.2.32-137.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby" release="137.oe2203sp4" version="3.0.3">
                         <filename>ruby-3.0.3-137.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby-debuginfo" release="137.oe2203sp4" version="3.0.3">
                         <filename>ruby-debuginfo-3.0.3-137.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby-debugsource" release="137.oe2203sp4" version="3.0.3">
                         <filename>ruby-debugsource-3.0.3-137.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby-devel" release="137.oe2203sp4" version="3.0.3">
                         <filename>ruby-devel-3.0.3-137.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-bigdecimal" release="137.oe2203sp4" version="3.0.0">
                         <filename>rubygem-bigdecimal-3.0.0-137.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-io-console" release="137.oe2203sp4" version="0.5.7">
                         <filename>rubygem-io-console-0.5.7-137.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-json" release="137.oe2203sp4" version="2.5.1">
                         <filename>rubygem-json-2.5.1-137.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-openssl" release="137.oe2203sp4" version="2.2.1">
                         <filename>rubygem-openssl-2.2.1-137.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-psych" release="137.oe2203sp4" version="3.3.2">
                         <filename>rubygem-psych-3.3.2-137.oe2203sp4.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-SP4</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.oe2203sp4" version="1.8.7">
                         <filename>python3-webob-1.8.7-3.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2047</id>
          <title>An update for libtiff is now available for openEuler-22.03-LTS-SP4</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.oe2203sp4" version="4.3.0">
                         <filename>libtiff-4.3.0-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-debuginfo" release="38.oe2203sp4" version="4.3.0">
                         <filename>libtiff-debuginfo-4.3.0-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-debugsource" release="38.oe2203sp4" version="4.3.0">
                         <filename>libtiff-debugsource-4.3.0-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-devel" release="38.oe2203sp4" version="4.3.0">
                         <filename>libtiff-devel-4.3.0-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-static" release="38.oe2203sp4" version="4.3.0">
                         <filename>libtiff-static-4.3.0-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-tools" release="38.oe2203sp4" version="4.3.0">
                         <filename>libtiff-tools-4.3.0-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="libtiff-help" release="38.oe2203sp4" version="4.3.0">
                         <filename>libtiff-help-4.3.0-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff" release="38.oe2203sp4" version="4.3.0">
                         <filename>libtiff-4.3.0-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-debuginfo" release="38.oe2203sp4" version="4.3.0">
                         <filename>libtiff-debuginfo-4.3.0-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-debugsource" release="38.oe2203sp4" version="4.3.0">
                         <filename>libtiff-debugsource-4.3.0-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-devel" release="38.oe2203sp4" version="4.3.0">
                         <filename>libtiff-devel-4.3.0-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-static" release="38.oe2203sp4" version="4.3.0">
                         <filename>libtiff-static-4.3.0-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-tools" release="38.oe2203sp4" version="4.3.0">
                         <filename>libtiff-tools-4.3.0-38.oe2203sp4.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-SP4</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.oe2203sp4" version="2.4.51">
                         <filename>httpd-2.4.51-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd-debuginfo" release="22.oe2203sp4" version="2.4.51">
                         <filename>httpd-debuginfo-2.4.51-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd-debugsource" release="22.oe2203sp4" version="2.4.51">
                         <filename>httpd-debugsource-2.4.51-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd-devel" release="22.oe2203sp4" version="2.4.51">
                         <filename>httpd-devel-2.4.51-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd-tools" release="22.oe2203sp4" version="2.4.51">
                         <filename>httpd-tools-2.4.51-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_ldap" release="22.oe2203sp4" version="2.4.51">
                         <filename>mod_ldap-2.4.51-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_md" release="22.oe2203sp4" version="2.4.51">
                         <filename>mod_md-2.4.51-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mod_proxy_html" release="22.oe2203sp4" version="2.4.51">
                         <filename>mod_proxy_html-2.4.51-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_session" release="22.oe2203sp4" version="2.4.51">
                         <filename>mod_session-2.4.51-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mod_ssl" release="22.oe2203sp4" version="2.4.51">
                         <filename>mod_ssl-2.4.51-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="httpd-filesystem" release="22.oe2203sp4" version="2.4.51">
                         <filename>httpd-filesystem-2.4.51-22.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="httpd-help" release="22.oe2203sp4" version="2.4.51">
                         <filename>httpd-help-2.4.51-22.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd" release="22.oe2203sp4" version="2.4.51">
                         <filename>httpd-2.4.51-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-debuginfo" release="22.oe2203sp4" version="2.4.51">
                         <filename>httpd-debuginfo-2.4.51-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-debugsource" release="22.oe2203sp4" version="2.4.51">
                         <filename>httpd-debugsource-2.4.51-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-devel" release="22.oe2203sp4" version="2.4.51">
                         <filename>httpd-devel-2.4.51-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-tools" release="22.oe2203sp4" version="2.4.51">
                         <filename>httpd-tools-2.4.51-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_ldap" release="22.oe2203sp4" version="2.4.51">
                         <filename>mod_ldap-2.4.51-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_md" release="22.oe2203sp4" version="2.4.51">
                         <filename>mod_md-2.4.51-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mod_proxy_html" release="22.oe2203sp4" version="2.4.51">
                         <filename>mod_proxy_html-2.4.51-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_session" release="22.oe2203sp4" version="2.4.51">
                         <filename>mod_session-2.4.51-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mod_ssl" release="22.oe2203sp4" version="2.4.51">
                         <filename>mod_ssl-2.4.51-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2052</id>
          <title>An update for python-twisted is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-08-23"></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.oe2203sp4" version="22.4.0">
                         <filename>python3-twisted-22.4.0-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="python-twisted-help" release="4.oe2203sp4" version="22.4.0">
                         <filename>python-twisted-help-22.4.0-4.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-twisted" release="4.oe2203sp4" version="22.4.0">
                         <filename>python3-twisted-22.4.0-4.oe2203sp4.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-SP4</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.oe2203sp4" version="1.10.2">
                         <filename>flatpak-1.10.2-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="flatpak-debuginfo" release="9.oe2203sp4" version="1.10.2">
                         <filename>flatpak-debuginfo-1.10.2-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="flatpak-debugsource" release="9.oe2203sp4" version="1.10.2">
                         <filename>flatpak-debugsource-1.10.2-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="flatpak-devel" release="9.oe2203sp4" version="1.10.2">
                         <filename>flatpak-devel-1.10.2-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="flatpak-help" release="9.oe2203sp4" version="1.10.2">
                         <filename>flatpak-help-1.10.2-9.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="flatpak" release="9.oe2203sp4" version="1.10.2">
                         <filename>flatpak-1.10.2-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="flatpak-debuginfo" release="9.oe2203sp4" version="1.10.2">
                         <filename>flatpak-debuginfo-1.10.2-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="flatpak-debugsource" release="9.oe2203sp4" version="1.10.2">
                         <filename>flatpak-debugsource-1.10.2-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="flatpak-devel" release="9.oe2203sp4" version="1.10.2">
                         <filename>flatpak-devel-1.10.2-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2055</id>
          <title>An update for postgresql is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-08-23"></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.oe2203sp4" version="13.16">
                         <filename>postgresql-13.16-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-contrib" release="1.oe2203sp4" version="13.16">
                         <filename>postgresql-contrib-13.16-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-debuginfo" release="1.oe2203sp4" version="13.16">
                         <filename>postgresql-debuginfo-13.16-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-debugsource" release="1.oe2203sp4" version="13.16">
                         <filename>postgresql-debugsource-13.16-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-docs" release="1.oe2203sp4" version="13.16">
                         <filename>postgresql-docs-13.16-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-llvmjit" release="1.oe2203sp4" version="13.16">
                         <filename>postgresql-llvmjit-13.16-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-plperl" release="1.oe2203sp4" version="13.16">
                         <filename>postgresql-plperl-13.16-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-plpython3" release="1.oe2203sp4" version="13.16">
                         <filename>postgresql-plpython3-13.16-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-pltcl" release="1.oe2203sp4" version="13.16">
                         <filename>postgresql-pltcl-13.16-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-private-devel" release="1.oe2203sp4" version="13.16">
                         <filename>postgresql-private-devel-13.16-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-private-libs" release="1.oe2203sp4" version="13.16">
                         <filename>postgresql-private-libs-13.16-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-server" release="1.oe2203sp4" version="13.16">
                         <filename>postgresql-server-13.16-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-server-devel" release="1.oe2203sp4" version="13.16">
                         <filename>postgresql-server-devel-13.16-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-static" release="1.oe2203sp4" version="13.16">
                         <filename>postgresql-static-13.16-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-test" release="1.oe2203sp4" version="13.16">
                         <filename>postgresql-test-13.16-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="postgresql-test-rpm-macros" release="1.oe2203sp4" version="13.16">
                         <filename>postgresql-test-rpm-macros-13.16-1.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql" release="1.oe2203sp4" version="13.16">
                         <filename>postgresql-13.16-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-contrib" release="1.oe2203sp4" version="13.16">
                         <filename>postgresql-contrib-13.16-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-debuginfo" release="1.oe2203sp4" version="13.16">
                         <filename>postgresql-debuginfo-13.16-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-debugsource" release="1.oe2203sp4" version="13.16">
                         <filename>postgresql-debugsource-13.16-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-docs" release="1.oe2203sp4" version="13.16">
                         <filename>postgresql-docs-13.16-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-llvmjit" release="1.oe2203sp4" version="13.16">
                         <filename>postgresql-llvmjit-13.16-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-plperl" release="1.oe2203sp4" version="13.16">
                         <filename>postgresql-plperl-13.16-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-plpython3" release="1.oe2203sp4" version="13.16">
                         <filename>postgresql-plpython3-13.16-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-pltcl" release="1.oe2203sp4" version="13.16">
                         <filename>postgresql-pltcl-13.16-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-private-devel" release="1.oe2203sp4" version="13.16">
                         <filename>postgresql-private-devel-13.16-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-private-libs" release="1.oe2203sp4" version="13.16">
                         <filename>postgresql-private-libs-13.16-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-server" release="1.oe2203sp4" version="13.16">
                         <filename>postgresql-server-13.16-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-server-devel" release="1.oe2203sp4" version="13.16">
                         <filename>postgresql-server-devel-13.16-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-static" release="1.oe2203sp4" version="13.16">
                         <filename>postgresql-static-13.16-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-test" release="1.oe2203sp4" version="13.16">
                         <filename>postgresql-test-13.16-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2059</id>
          <title>An update for golang is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-08-23"></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.oe2203sp4" version="1.17.3">
                         <filename>golang-1.17.3-35.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="golang-devel" release="35.oe2203sp4" version="1.17.3">
                         <filename>golang-devel-1.17.3-35.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="golang-help" release="35.oe2203sp4" version="1.17.3">
                         <filename>golang-help-1.17.3-35.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="golang" release="35.oe2203sp4" version="1.17.3">
                         <filename>golang-1.17.3-35.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2065</id>
          <title>An update for nginx is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-08-30"></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.oe2203sp4" version="1.21.5">
                         <filename>nginx-1.21.5-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nginx-debuginfo" release="7.oe2203sp4" version="1.21.5">
                         <filename>nginx-debuginfo-1.21.5-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nginx-debugsource" release="7.oe2203sp4" version="1.21.5">
                         <filename>nginx-debugsource-1.21.5-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nginx-mod-devel" release="7.oe2203sp4" version="1.21.5">
                         <filename>nginx-mod-devel-1.21.5-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nginx-mod-http-image-filter" release="7.oe2203sp4" version="1.21.5">
                         <filename>nginx-mod-http-image-filter-1.21.5-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nginx-mod-http-perl" release="7.oe2203sp4" version="1.21.5">
                         <filename>nginx-mod-http-perl-1.21.5-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nginx-mod-http-xslt-filter" release="7.oe2203sp4" version="1.21.5">
                         <filename>nginx-mod-http-xslt-filter-1.21.5-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nginx-mod-mail" release="7.oe2203sp4" version="1.21.5">
                         <filename>nginx-mod-mail-1.21.5-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nginx-mod-stream" release="7.oe2203sp4" version="1.21.5">
                         <filename>nginx-mod-stream-1.21.5-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="nginx-all-modules" release="7.oe2203sp4" version="1.21.5">
                         <filename>nginx-all-modules-1.21.5-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="nginx-filesystem" release="7.oe2203sp4" version="1.21.5">
                         <filename>nginx-filesystem-1.21.5-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="nginx-help" release="7.oe2203sp4" version="1.21.5">
                         <filename>nginx-help-1.21.5-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nginx" release="7.oe2203sp4" version="1.21.5">
                         <filename>nginx-1.21.5-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nginx-debuginfo" release="7.oe2203sp4" version="1.21.5">
                         <filename>nginx-debuginfo-1.21.5-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nginx-debugsource" release="7.oe2203sp4" version="1.21.5">
                         <filename>nginx-debugsource-1.21.5-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nginx-mod-devel" release="7.oe2203sp4" version="1.21.5">
                         <filename>nginx-mod-devel-1.21.5-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nginx-mod-http-image-filter" release="7.oe2203sp4" version="1.21.5">
                         <filename>nginx-mod-http-image-filter-1.21.5-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nginx-mod-http-perl" release="7.oe2203sp4" version="1.21.5">
                         <filename>nginx-mod-http-perl-1.21.5-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nginx-mod-http-xslt-filter" release="7.oe2203sp4" version="1.21.5">
                         <filename>nginx-mod-http-xslt-filter-1.21.5-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nginx-mod-mail" release="7.oe2203sp4" version="1.21.5">
                         <filename>nginx-mod-mail-1.21.5-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nginx-mod-stream" release="7.oe2203sp4" version="1.21.5">
                         <filename>nginx-mod-stream-1.21.5-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2069</id>
          <title>An update for netty3 is now available for openEuler-22.03-LTS-SP4</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.oe2203sp4" version="3.10.6">
                         <filename>netty3-3.10.6-8.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2077</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-08-30"></issued>
          <references>
               <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-2024-39490" id="CVE-2024-39490" title="CVE-2024-39490" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41015" id="CVE-2024-41015" title="CVE-2024-41015" 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-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-42288" id="CVE-2024-42288" title="CVE-2024-42288" 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-42302" id="CVE-2024-42302" title="CVE-2024-42302" 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-42318" id="CVE-2024-42318" title="CVE-2024-42318" 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: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: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:ocfs2: add bounds checking to ocfs2_check_dir_entry()This adds sanity checks for ocfs2_dir_entry to make sure all members ofocfs2_dir_entry don&#39;t stray beyond valid memory region.(CVE-2024-41015)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: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: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: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:PCI/DPC: Fix use-after-free on concurrent DPC and hot-removalKeith reports a use-after-free when a DPC event occurs concurrently tohot-removal of the same portion of the hierarchy:The dpc_handler() awaits readiness of the secondary bus below theDownstream Port where the DPC event occurred.  To do so, it polls theconfig space of the first child device on the secondary bus.  If thatchild device is concurrently removed, accesses to its struct pci_devcause the kernel to oops.That&#39;s because pci_bridge_wait_for_secondary_bus() neglects to hold areference on the child device.  Before v6.3, the function was onlycalled on resume from system sleep or on runtime resume.  Holding areference wasn&#39;t necessary back then because the pciehp IRQ threadcould never run concurrently.  (On resume from system sleep, IRQs arenot enabled until after the resume_noirq phase.  And runtime resume isalways awaited before a PCI device is removed.)However starting with v6.3, pci_bridge_wait_for_secondary_bus() is alsocalled on a DPC event.  Commit 53b54ad074de (&#34;PCI/DPC: Await readinessof secondary bus after reset&#34;), which introduced that, failed toappreciate that pci_bridge_wait_for_secondary_bus() now needs to hold areference on the child device because dpc_handler() and pciehp mayindeed run concurrently.  The commit was backported to v5.10+ stablekernels, so that&#39;s the oldest one affected.Add the missing reference acquisition.Abridged stack trace:  BUG: unable to handle page fault for address: 00000000091400c0  CPU: 15 PID: 2464 Comm: irq/53-pcie-dpc 6.9.0  RIP: pci_bus_read_config_dword+0x17/0x50  pci_dev_wait()  pci_bridge_wait_for_secondary_bus()  dpc_reset_link()  pcie_do_recovery()  dpc_handler()(CVE-2024-42302)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:landlock: Don&#39;t lose track of restrictions on cred_transferWhen a process&#39; cred struct is replaced, this _almost_ always invokesthe cred_prepare LSM hook; but in one special case (whenKEYCTL_SESSION_TO_PARENT updates the parent&#39;s credentials), thecred_transfer LSM hook is used instead.  Landlock only implements thecred_prepare hook, not cred_transfer, so KEYCTL_SESSION_TO_PARENT causesall information on Landlock restrictions to be lost.This basically means that a process with the ability to use the fork()and keyctl() syscalls can get rid of all Landlock restrictions onitself.Fix it by adding a cred_transfer hook that does the same thing as theexisting cred_prepare hook. (Implemented by having hook_cred_prepare()call hook_cred_transfer() so that the two functions are less likely toaccidentally diverge in the future.)(CVE-2024-42318)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="bpftool" release="225.0.0.124.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-225.0.0.124.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="225.0.0.124.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-225.0.0.124.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="225.0.0.124.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-225.0.0.124.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="225.0.0.124.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-225.0.0.124.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="225.0.0.124.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-225.0.0.124.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="225.0.0.124.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-225.0.0.124.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="225.0.0.124.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-225.0.0.124.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="225.0.0.124.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-225.0.0.124.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="225.0.0.124.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-225.0.0.124.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="225.0.0.124.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-225.0.0.124.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="225.0.0.124.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-225.0.0.124.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="225.0.0.124.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-225.0.0.124.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="225.0.0.124.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-225.0.0.124.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="225.0.0.124.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-225.0.0.124.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="225.0.0.124.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-225.0.0.124.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="225.0.0.124.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-225.0.0.124.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="225.0.0.124.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-225.0.0.124.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="225.0.0.124.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-225.0.0.124.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="225.0.0.124.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-225.0.0.124.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="225.0.0.124.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-225.0.0.124.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="225.0.0.124.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-225.0.0.124.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="225.0.0.124.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-225.0.0.124.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="225.0.0.124.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-225.0.0.124.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="225.0.0.124.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-225.0.0.124.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="225.0.0.124.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-225.0.0.124.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="225.0.0.124.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-225.0.0.124.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="225.0.0.124.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-225.0.0.124.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="225.0.0.124.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-225.0.0.124.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="225.0.0.124.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-225.0.0.124.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="225.0.0.124.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-225.0.0.124.oe2203sp4.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-SP4</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-debuginfo" release="7.oe2203sp4" version="2.36.3">
                         <filename>webkit2gtk3-debuginfo-2.36.3-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="webkit2gtk3" release="7.oe2203sp4" version="2.36.3">
                         <filename>webkit2gtk3-2.36.3-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="webkit2gtk3-debugsource" release="7.oe2203sp4" version="2.36.3">
                         <filename>webkit2gtk3-debugsource-2.36.3-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="webkit2gtk3-devel" release="7.oe2203sp4" version="2.36.3">
                         <filename>webkit2gtk3-devel-2.36.3-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="webkit2gtk3-jsc-devel" release="7.oe2203sp4" version="2.36.3">
                         <filename>webkit2gtk3-jsc-devel-2.36.3-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="webkit2gtk3-jsc" release="7.oe2203sp4" version="2.36.3">
                         <filename>webkit2gtk3-jsc-2.36.3-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="webkit2gtk3-help" release="7.oe2203sp4" version="2.36.3">
                         <filename>webkit2gtk3-help-2.36.3-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="webkit2gtk3" release="7.oe2203sp4" version="2.36.3">
                         <filename>webkit2gtk3-2.36.3-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="webkit2gtk3-jsc" release="7.oe2203sp4" version="2.36.3">
                         <filename>webkit2gtk3-jsc-2.36.3-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="webkit2gtk3-devel" release="7.oe2203sp4" version="2.36.3">
                         <filename>webkit2gtk3-devel-2.36.3-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="webkit2gtk3-debugsource" release="7.oe2203sp4" version="2.36.3">
                         <filename>webkit2gtk3-debugsource-2.36.3-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="webkit2gtk3-debuginfo" release="7.oe2203sp4" version="2.36.3">
                         <filename>webkit2gtk3-debuginfo-2.36.3-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="webkit2gtk3-jsc-devel" release="7.oe2203sp4" version="2.36.3">
                         <filename>webkit2gtk3-jsc-devel-2.36.3-7.oe2203sp4.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-SP4</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.oe2203sp4" version="3.6.14">
                         <filename>wireshark-3.6.14-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-debuginfo" release="9.oe2203sp4" version="3.6.14">
                         <filename>wireshark-debuginfo-3.6.14-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-debugsource" release="9.oe2203sp4" version="3.6.14">
                         <filename>wireshark-debugsource-3.6.14-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-devel" release="9.oe2203sp4" version="3.6.14">
                         <filename>wireshark-devel-3.6.14-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-help" release="9.oe2203sp4" version="3.6.14">
                         <filename>wireshark-help-3.6.14-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark" release="9.oe2203sp4" version="3.6.14">
                         <filename>wireshark-3.6.14-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-debuginfo" release="9.oe2203sp4" version="3.6.14">
                         <filename>wireshark-debuginfo-3.6.14-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-debugsource" release="9.oe2203sp4" version="3.6.14">
                         <filename>wireshark-debugsource-3.6.14-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-devel" release="9.oe2203sp4" version="3.6.14">
                         <filename>wireshark-devel-3.6.14-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-help" release="9.oe2203sp4" version="3.6.14">
                         <filename>wireshark-help-3.6.14-9.oe2203sp4.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-SP4</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.oe2203sp4" version="6.04">
                         <filename>syslinux-extlinux-nonlinux-6.04-16.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="syslinux-nonlinux" release="16.oe2203sp4" version="6.04">
                         <filename>syslinux-nonlinux-6.04-16.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="syslinux-tftpboot" release="16.oe2203sp4" version="6.04">
                         <filename>syslinux-tftpboot-6.04-16.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="syslinux" release="16.oe2203sp4" version="6.04">
                         <filename>syslinux-6.04-16.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="syslinux-debuginfo" release="16.oe2203sp4" version="6.04">
                         <filename>syslinux-debuginfo-6.04-16.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="syslinux-debugsource" release="16.oe2203sp4" version="6.04">
                         <filename>syslinux-debugsource-6.04-16.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="syslinux-devel" release="16.oe2203sp4" version="6.04">
                         <filename>syslinux-devel-6.04-16.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="syslinux-efi64" release="16.oe2203sp4" version="6.04">
                         <filename>syslinux-efi64-6.04-16.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="syslinux-extlinux" release="16.oe2203sp4" version="6.04">
                         <filename>syslinux-extlinux-6.04-16.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="syslinux-perl" release="16.oe2203sp4" version="6.04">
                         <filename>syslinux-perl-6.04-16.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2092</id>
          <title>An update for edk2 is now available for openEuler-22.03-LTS-SP4</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.oe2203sp4" version="202011">
                         <filename>edk2-debuginfo-202011-20.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="edk2-debugsource" release="20.oe2203sp4" version="202011">
                         <filename>edk2-debugsource-202011-20.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="edk2-devel" release="20.oe2203sp4" version="202011">
                         <filename>edk2-devel-202011-20.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-aarch64" release="20.oe2203sp4" version="202011">
                         <filename>edk2-aarch64-202011-20.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-help" release="20.oe2203sp4" version="202011">
                         <filename>edk2-help-202011-20.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-ovmf" release="20.oe2203sp4" version="202011">
                         <filename>edk2-ovmf-202011-20.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-edk2-devel" release="20.oe2203sp4" version="202011">
                         <filename>python3-edk2-devel-202011-20.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-debuginfo" release="20.oe2203sp4" version="202011">
                         <filename>edk2-debuginfo-202011-20.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-debugsource" release="20.oe2203sp4" version="202011">
                         <filename>edk2-debugsource-202011-20.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-devel" release="20.oe2203sp4" version="202011">
                         <filename>edk2-devel-202011-20.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2100</id>
          <title>An update for firefox is now available for openEuler-22.03-LTS-SP4</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.oe2203sp4" version="102.15.0">
                         <filename>firefox-102.15.0-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="firefox-debuginfo" release="7.oe2203sp4" version="102.15.0">
                         <filename>firefox-debuginfo-102.15.0-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="firefox-debugsource" release="7.oe2203sp4" version="102.15.0">
                         <filename>firefox-debugsource-102.15.0-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox" release="7.oe2203sp4" version="102.15.0">
                         <filename>firefox-102.15.0-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox-debuginfo" release="7.oe2203sp4" version="102.15.0">
                         <filename>firefox-debuginfo-102.15.0-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox-debugsource" release="7.oe2203sp4" version="102.15.0">
                         <filename>firefox-debugsource-102.15.0-7.oe2203sp4.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-SP4</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.oe2203sp4" version="2.4.51">
                         <filename>httpd-2.4.51-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd-debuginfo" release="22.oe2203sp4" version="2.4.51">
                         <filename>httpd-debuginfo-2.4.51-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd-debugsource" release="22.oe2203sp4" version="2.4.51">
                         <filename>httpd-debugsource-2.4.51-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd-devel" release="22.oe2203sp4" version="2.4.51">
                         <filename>httpd-devel-2.4.51-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd-tools" release="22.oe2203sp4" version="2.4.51">
                         <filename>httpd-tools-2.4.51-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_ldap" release="22.oe2203sp4" version="2.4.51">
                         <filename>mod_ldap-2.4.51-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_md" release="22.oe2203sp4" version="2.4.51">
                         <filename>mod_md-2.4.51-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mod_proxy_html" release="22.oe2203sp4" version="2.4.51">
                         <filename>mod_proxy_html-2.4.51-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_session" release="22.oe2203sp4" version="2.4.51">
                         <filename>mod_session-2.4.51-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mod_ssl" release="22.oe2203sp4" version="2.4.51">
                         <filename>mod_ssl-2.4.51-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="httpd-filesystem" release="22.oe2203sp4" version="2.4.51">
                         <filename>httpd-filesystem-2.4.51-22.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="httpd-help" release="22.oe2203sp4" version="2.4.51">
                         <filename>httpd-help-2.4.51-22.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd" release="22.oe2203sp4" version="2.4.51">
                         <filename>httpd-2.4.51-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-debuginfo" release="22.oe2203sp4" version="2.4.51">
                         <filename>httpd-debuginfo-2.4.51-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-debugsource" release="22.oe2203sp4" version="2.4.51">
                         <filename>httpd-debugsource-2.4.51-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-devel" release="22.oe2203sp4" version="2.4.51">
                         <filename>httpd-devel-2.4.51-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-tools" release="22.oe2203sp4" version="2.4.51">
                         <filename>httpd-tools-2.4.51-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_ldap" release="22.oe2203sp4" version="2.4.51">
                         <filename>mod_ldap-2.4.51-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_md" release="22.oe2203sp4" version="2.4.51">
                         <filename>mod_md-2.4.51-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mod_proxy_html" release="22.oe2203sp4" version="2.4.51">
                         <filename>mod_proxy_html-2.4.51-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_session" release="22.oe2203sp4" version="2.4.51">
                         <filename>mod_session-2.4.51-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mod_ssl" release="22.oe2203sp4" version="2.4.51">
                         <filename>mod_ssl-2.4.51-22.oe2203sp4.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-SP4</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.oe2203sp4" version="2.4.1">
                         <filename>expat-2.4.1-12.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="expat-debuginfo" release="12.oe2203sp4" version="2.4.1">
                         <filename>expat-debuginfo-2.4.1-12.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="expat-debugsource" release="12.oe2203sp4" version="2.4.1">
                         <filename>expat-debugsource-2.4.1-12.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="expat-devel" release="12.oe2203sp4" version="2.4.1">
                         <filename>expat-devel-2.4.1-12.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="expat-help" release="12.oe2203sp4" version="2.4.1">
                         <filename>expat-help-2.4.1-12.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="expat" release="12.oe2203sp4" version="2.4.1">
                         <filename>expat-2.4.1-12.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="expat-debuginfo" release="12.oe2203sp4" version="2.4.1">
                         <filename>expat-debuginfo-2.4.1-12.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="expat-debugsource" release="12.oe2203sp4" version="2.4.1">
                         <filename>expat-debugsource-2.4.1-12.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="expat-devel" release="12.oe2203sp4" version="2.4.1">
                         <filename>expat-devel-2.4.1-12.oe2203sp4.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-SP4</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.oe2203sp4" version="20240811">
                         <filename>linux-firmware-20240811-1.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="linux-firmware-ath" release="1.oe2203sp4" version="20240811">
                         <filename>linux-firmware-ath-20240811-1.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="linux-firmware-cypress" release="1.oe2203sp4" version="20240811">
                         <filename>linux-firmware-cypress-20240811-1.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="linux-firmware-iwlwifi" release="1.oe2203sp4" version="20240811">
                         <filename>linux-firmware-iwlwifi-20240811-1.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="linux-firmware-libertas" release="1.oe2203sp4" version="20240811">
                         <filename>linux-firmware-libertas-20240811-1.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="linux-firmware-mediatek" release="1.oe2203sp4" version="20240811">
                         <filename>linux-firmware-mediatek-20240811-1.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="linux-firmware-mrvl" release="1.oe2203sp4" version="20240811">
                         <filename>linux-firmware-mrvl-20240811-1.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="linux-firmware-netronome" release="1.oe2203sp4" version="20240811">
                         <filename>linux-firmware-netronome-20240811-1.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="linux-firmware-ti-connectivity" release="1.oe2203sp4" version="20240811">
                         <filename>linux-firmware-ti-connectivity-20240811-1.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2105</id>
          <title>An update for exim is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-09-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39929" id="CVE-2024-39929" title="CVE-2024-39929" type="cve"></reference>
          </references>
          <description>Exim through 4.97.1 misparses a multiline RFC 2231 header filename, and thus remote attackers can bypass a $mime_filename extension-blocking protection mechanism, and potentially deliver executable attachments to the mailboxes of end users.(CVE-2024-39929)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="exim" release="4.oe2203sp4" version="4.96">
                         <filename>exim-4.96-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="exim-clamav" release="4.oe2203sp4" version="4.96">
                         <filename>exim-clamav-4.96-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="exim-debuginfo" release="4.oe2203sp4" version="4.96">
                         <filename>exim-debuginfo-4.96-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="exim-debugsource" release="4.oe2203sp4" version="4.96">
                         <filename>exim-debugsource-4.96-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="exim-greylist" release="4.oe2203sp4" version="4.96">
                         <filename>exim-greylist-4.96-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="exim-mon" release="4.oe2203sp4" version="4.96">
                         <filename>exim-mon-4.96-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="exim-mysql" release="4.oe2203sp4" version="4.96">
                         <filename>exim-mysql-4.96-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="exim-pgsql" release="4.oe2203sp4" version="4.96">
                         <filename>exim-pgsql-4.96-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="exim" release="4.oe2203sp4" version="4.96">
                         <filename>exim-4.96-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="exim-clamav" release="4.oe2203sp4" version="4.96">
                         <filename>exim-clamav-4.96-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="exim-debuginfo" release="4.oe2203sp4" version="4.96">
                         <filename>exim-debuginfo-4.96-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="exim-debugsource" release="4.oe2203sp4" version="4.96">
                         <filename>exim-debugsource-4.96-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="exim-greylist" release="4.oe2203sp4" version="4.96">
                         <filename>exim-greylist-4.96-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="exim-mon" release="4.oe2203sp4" version="4.96">
                         <filename>exim-mon-4.96-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="exim-mysql" release="4.oe2203sp4" version="4.96">
                         <filename>exim-mysql-4.96-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="exim-pgsql" release="4.oe2203sp4" version="4.96">
                         <filename>exim-pgsql-4.96-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2107</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP4</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-2023-52889" id="CVE-2023-52889" title="CVE-2023-52889" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27012" id="CVE-2024-27012" title="CVE-2024-27012" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27065" id="CVE-2024-27065" title="CVE-2024-27065" 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-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-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-42286" id="CVE-2024-42286" title="CVE-2024-42286" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42287" id="CVE-2024-42287" title="CVE-2024-42287" 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-43902" id="CVE-2024-43902" title="CVE-2024-43902" 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-44942" id="CVE-2024-44942" title="CVE-2024-44942" 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: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:netfilter: nf_tables: restore set elements when delete set failsFrom abort path, nft_mapelem_activate() needs to restore refcounters tothe original state. Currently, it uses the set-&gt;ops-&gt;walk() to iterateover these set elements. The existing set iterator skips inactiveelements in the next generation, this does not work from the abort pathto restore the original state since it has to skip active elementsinstead (not inactive ones).This patch moves the check for inactive elements to the set iteratorcallback, then it reverses the logic for the .activate case whichneeds to skip active elements.Toggle next generation bit for elements when delete set command isinvoked and call nft_clear() from .activate (abort) path to restore thenext generation bit.The splat below shows an object in mappings memleak:[43929.457523] ------------[ cut here ]------------[43929.457532] WARNING: CPU: 0 PID: 1139 at include/net/netfilter/nf_tables.h:1237 nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables][...][43929.458014] RIP: 0010:nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables][43929.458076] Code: 83 f8 01 77 ab 49 8d 7c 24 08 e8 37 5e d0 de 49 8b 6c 24 08 48 8d 7d 50 e8 e9 5c d0 de 8b 45 50 8d 50 ff 89 55 50 85 c0 75 86 &lt;0f&gt; 0b eb 82 0f 0b eb b3 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90[43929.458081] RSP: 0018:ffff888140f9f4b0 EFLAGS: 00010246[43929.458086] RAX: 0000000000000000 RBX: ffff8881434f5288 RCX: dffffc0000000000[43929.458090] RDX: 00000000ffffffff RSI: ffffffffa26d28a7 RDI: ffff88810ecc9550[43929.458093] RBP: ffff88810ecc9500 R08: 0000000000000001 R09: ffffed10281f3e8f[43929.458096] R10: 0000000000000003 R11: ffff0000ffff0000 R12: ffff8881434f52a0[43929.458100] R13: ffff888140f9f5f4 R14: ffff888151c7a800 R15: 0000000000000002[43929.458103] FS:  00007f0c687c4740(0000) GS:ffff888390800000(0000) knlGS:0000000000000000[43929.458107] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033[43929.458111] CR2: 00007f58dbe5b008 CR3: 0000000123602005 CR4: 00000000001706f0[43929.458114] Call Trace:[43929.458118]  &lt;TASK&gt;[43929.458121]  ? __warn+0x9f/0x1a0[43929.458127]  ? nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables][43929.458188]  ? report_bug+0x1b1/0x1e0[43929.458196]  ? handle_bug+0x3c/0x70[43929.458200]  ? exc_invalid_op+0x17/0x40[43929.458211]  ? nft_setelem_data_deactivate+0xd7/0xf0 [nf_tables][43929.458271]  ? nft_setelem_data_deactivate+0xe4/0xf0 [nf_tables][43929.458332]  nft_mapelem_deactivate+0x24/0x30 [nf_tables][43929.458392]  nft_rhash_walk+0xdd/0x180 [nf_tables][43929.458453]  ? __pfx_nft_rhash_walk+0x10/0x10 [nf_tables][43929.458512]  ? rb_insert_color+0x2e/0x280[43929.458520]  nft_map_deactivate+0xdc/0x1e0 [nf_tables][43929.458582]  ? __pfx_nft_map_deactivate+0x10/0x10 [nf_tables][43929.458642]  ? __pfx_nft_mapelem_deactivate+0x10/0x10 [nf_tables][43929.458701]  ? __rcu_read_unlock+0x46/0x70[43929.458709]  nft_delset+0xff/0x110 [nf_tables][43929.458769]  nft_flush_table+0x16f/0x460 [nf_tables][43929.458830]  nf_tables_deltable+0x501/0x580 [nf_tables](CVE-2024-27012)In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: do not compare internal table flags on updatesRestore skipping transaction if table update does not modify flags.(CVE-2024-27065)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: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: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: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: Complete command early within lockA crash was observed while performing NPIV and FW reset, BUG: kernel NULL pointer dereference, address: 000000000000001c #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 1 PREEMPT_RT SMP NOPTI RIP: 0010:dma_direct_unmap_sg+0x51/0x1e0 RSP: 0018:ffffc90026f47b88 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000021 RCX: 0000000000000002 RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff8881041130d0 RBP: ffff8881041130d0 R08: 0000000000000000 R09: 0000000000000034 R10: ffffc90026f47c48 R11: 0000000000000031 R12: 0000000000000000 R13: 0000000000000000 R14: ffff8881565e4a20 R15: 0000000000000000 FS: 00007f4c69ed3d00(0000) GS:ffff889faac80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000001c CR3: 0000000288a50002 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: &lt;TASK&gt; ? __die_body+0x1a/0x60 ? page_fault_oops+0x16f/0x4a0 ? do_user_addr_fault+0x174/0x7f0 ? exc_page_fault+0x69/0x1a0 ? asm_exc_page_fault+0x22/0x30 ? dma_direct_unmap_sg+0x51/0x1e0 ? preempt_count_sub+0x96/0xe0 qla2xxx_qpair_sp_free_dma+0x29f/0x3b0 [qla2xxx] qla2xxx_qpair_sp_compl+0x60/0x80 [qla2xxx] __qla2x00_abort_all_cmds+0xa2/0x450 [qla2xxx]The command completion was done early while aborting the commands in driverunload path but outside lock to avoid the WARN_ON condition of performingdma_free_attr within the lock. However this caused race condition whilecommand completion via multiple paths causing system crash.Hence complete the command early in unload path but within the lock toavoid race condition.(CVE-2024-42287)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/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/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: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: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="bpftool" release="226.0.0.125.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-226.0.0.125.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="226.0.0.125.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-226.0.0.125.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="226.0.0.125.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-226.0.0.125.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="226.0.0.125.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-226.0.0.125.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="226.0.0.125.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-226.0.0.125.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="226.0.0.125.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-226.0.0.125.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="226.0.0.125.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-226.0.0.125.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="226.0.0.125.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-226.0.0.125.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="226.0.0.125.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-226.0.0.125.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="226.0.0.125.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-226.0.0.125.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="226.0.0.125.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-226.0.0.125.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="226.0.0.125.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-226.0.0.125.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="226.0.0.125.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-226.0.0.125.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="226.0.0.125.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-226.0.0.125.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="226.0.0.125.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-226.0.0.125.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="226.0.0.125.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-226.0.0.125.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="226.0.0.125.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-226.0.0.125.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="226.0.0.125.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-226.0.0.125.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="226.0.0.125.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-226.0.0.125.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="226.0.0.125.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-226.0.0.125.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="226.0.0.125.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-226.0.0.125.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="226.0.0.125.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-226.0.0.125.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="226.0.0.125.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-226.0.0.125.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="226.0.0.125.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-226.0.0.125.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="226.0.0.125.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-226.0.0.125.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="226.0.0.125.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-226.0.0.125.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="226.0.0.125.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-226.0.0.125.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="226.0.0.125.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-226.0.0.125.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="226.0.0.125.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-226.0.0.125.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="226.0.0.125.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-226.0.0.125.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2111</id>
          <title>An update for jbig2dec is now available for openEuler-22.03-LTS-SP4</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.oe2203sp4" version="0.19">
                         <filename>jbig2dec-0.19-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="jbig2dec-debuginfo" release="5.oe2203sp4" version="0.19">
                         <filename>jbig2dec-debuginfo-0.19-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="jbig2dec-debugsource" release="5.oe2203sp4" version="0.19">
                         <filename>jbig2dec-debugsource-0.19-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="jbig2dec-devel" release="5.oe2203sp4" version="0.19">
                         <filename>jbig2dec-devel-0.19-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="jbig2dec-help" release="5.oe2203sp4" version="0.19">
                         <filename>jbig2dec-help-0.19-5.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="jbig2dec" release="5.oe2203sp4" version="0.19">
                         <filename>jbig2dec-0.19-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="jbig2dec-debuginfo" release="5.oe2203sp4" version="0.19">
                         <filename>jbig2dec-debuginfo-0.19-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="jbig2dec-debugsource" release="5.oe2203sp4" version="0.19">
                         <filename>jbig2dec-debugsource-0.19-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="jbig2dec-devel" release="5.oe2203sp4" version="0.19">
                         <filename>jbig2dec-devel-0.19-5.oe2203sp4.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-SP4</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.oe2203sp4" version="3.0.3">
                         <filename>ruby-3.0.3-139.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ruby-debuginfo" release="139.oe2203sp4" version="3.0.3">
                         <filename>ruby-debuginfo-3.0.3-139.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ruby-debugsource" release="139.oe2203sp4" version="3.0.3">
                         <filename>ruby-debugsource-3.0.3-139.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ruby-devel" release="139.oe2203sp4" version="3.0.3">
                         <filename>ruby-devel-3.0.3-139.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-bigdecimal" release="139.oe2203sp4" version="3.0.0">
                         <filename>rubygem-bigdecimal-3.0.0-139.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-io-console" release="139.oe2203sp4" version="0.5.7">
                         <filename>rubygem-io-console-0.5.7-139.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-json" release="139.oe2203sp4" version="2.5.1">
                         <filename>rubygem-json-2.5.1-139.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-openssl" release="139.oe2203sp4" version="2.2.1">
                         <filename>rubygem-openssl-2.2.1-139.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-psych" release="139.oe2203sp4" version="3.3.2">
                         <filename>rubygem-psych-3.3.2-139.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="ruby-help" release="139.oe2203sp4" version="3.0.3">
                         <filename>ruby-help-3.0.3-139.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="ruby-irb" release="139.oe2203sp4" version="3.0.3">
                         <filename>ruby-irb-3.0.3-139.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-bundler" release="139.oe2203sp4" version="2.2.32">
                         <filename>rubygem-bundler-2.2.32-139.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-did_you_mean" release="139.oe2203sp4" version="1.5.0">
                         <filename>rubygem-did_you_mean-1.5.0-139.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-minitest" release="139.oe2203sp4" version="5.14.2">
                         <filename>rubygem-minitest-5.14.2-139.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rake" release="139.oe2203sp4" version="13.0.3">
                         <filename>rubygem-rake-13.0.3-139.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rbs" release="139.oe2203sp4" version="1.4.0">
                         <filename>rubygem-rbs-1.4.0-139.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rdoc" release="139.oe2203sp4" version="6.3.3">
                         <filename>rubygem-rdoc-6.3.3-139.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rexml" release="139.oe2203sp4" version="3.2.5">
                         <filename>rubygem-rexml-3.2.5-139.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rss" release="139.oe2203sp4" version="0.2.9">
                         <filename>rubygem-rss-0.2.9-139.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-test-unit" release="139.oe2203sp4" version="3.3.7">
                         <filename>rubygem-test-unit-3.3.7-139.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-typeprof" release="139.oe2203sp4" version="0.15.2">
                         <filename>rubygem-typeprof-0.15.2-139.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygems" release="139.oe2203sp4" version="3.2.32">
                         <filename>rubygems-3.2.32-139.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygems-devel" release="139.oe2203sp4" version="3.2.32">
                         <filename>rubygems-devel-3.2.32-139.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby" release="139.oe2203sp4" version="3.0.3">
                         <filename>ruby-3.0.3-139.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby-debuginfo" release="139.oe2203sp4" version="3.0.3">
                         <filename>ruby-debuginfo-3.0.3-139.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby-debugsource" release="139.oe2203sp4" version="3.0.3">
                         <filename>ruby-debugsource-3.0.3-139.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby-devel" release="139.oe2203sp4" version="3.0.3">
                         <filename>ruby-devel-3.0.3-139.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-bigdecimal" release="139.oe2203sp4" version="3.0.0">
                         <filename>rubygem-bigdecimal-3.0.0-139.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-io-console" release="139.oe2203sp4" version="0.5.7">
                         <filename>rubygem-io-console-0.5.7-139.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-json" release="139.oe2203sp4" version="2.5.1">
                         <filename>rubygem-json-2.5.1-139.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-openssl" release="139.oe2203sp4" version="2.2.1">
                         <filename>rubygem-openssl-2.2.1-139.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-psych" release="139.oe2203sp4" version="3.3.2">
                         <filename>rubygem-psych-3.3.2-139.oe2203sp4.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-SP4</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.oe2203sp4" version="9.0">
                         <filename>vim-X11-9.0-27.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-common" release="27.oe2203sp4" version="9.0">
                         <filename>vim-common-9.0-27.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-debuginfo" release="27.oe2203sp4" version="9.0">
                         <filename>vim-debuginfo-9.0-27.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-debugsource" release="27.oe2203sp4" version="9.0">
                         <filename>vim-debugsource-9.0-27.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-enhanced" release="27.oe2203sp4" version="9.0">
                         <filename>vim-enhanced-9.0-27.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-minimal" release="27.oe2203sp4" version="9.0">
                         <filename>vim-minimal-9.0-27.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="noarch" name="vim-filesystem" release="27.oe2203sp4" version="9.0">
                         <filename>vim-filesystem-9.0-27.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-X11" release="27.oe2203sp4" version="9.0">
                         <filename>vim-X11-9.0-27.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-common" release="27.oe2203sp4" version="9.0">
                         <filename>vim-common-9.0-27.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-debuginfo" release="27.oe2203sp4" version="9.0">
                         <filename>vim-debuginfo-9.0-27.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-debugsource" release="27.oe2203sp4" version="9.0">
                         <filename>vim-debugsource-9.0-27.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-enhanced" release="27.oe2203sp4" version="9.0">
                         <filename>vim-enhanced-9.0-27.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-minimal" release="27.oe2203sp4" version="9.0">
                         <filename>vim-minimal-9.0-27.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2119</id>
          <title>An update for python3 is now available for openEuler-22.03-LTS-SP4</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="35.oe2203sp4" version="3.9.9">
                         <filename>python3-3.9.9-35.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-debug" release="35.oe2203sp4" version="3.9.9">
                         <filename>python3-debug-3.9.9-35.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-debuginfo" release="35.oe2203sp4" version="3.9.9">
                         <filename>python3-debuginfo-3.9.9-35.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-debugsource" release="35.oe2203sp4" version="3.9.9">
                         <filename>python3-debugsource-3.9.9-35.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-devel" release="35.oe2203sp4" version="3.9.9">
                         <filename>python3-devel-3.9.9-35.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-unversioned-command" release="35.oe2203sp4" version="3.9.9">
                         <filename>python3-unversioned-command-3.9.9-35.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-help" release="35.oe2203sp4" version="3.9.9">
                         <filename>python3-help-3.9.9-35.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3" release="35.oe2203sp4" version="3.9.9">
                         <filename>python3-3.9.9-35.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-debug" release="35.oe2203sp4" version="3.9.9">
                         <filename>python3-debug-3.9.9-35.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-debuginfo" release="35.oe2203sp4" version="3.9.9">
                         <filename>python3-debuginfo-3.9.9-35.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-debugsource" release="35.oe2203sp4" version="3.9.9">
                         <filename>python3-debugsource-3.9.9-35.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-devel" release="35.oe2203sp4" version="3.9.9">
                         <filename>python3-devel-3.9.9-35.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-unversioned-command" release="35.oe2203sp4" version="3.9.9">
                         <filename>python3-unversioned-command-3.9.9-35.oe2203sp4.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-SP4</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.oe2203sp4" version="2.4.1">
                         <filename>expat-2.4.1-13.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="expat-debuginfo" release="13.oe2203sp4" version="2.4.1">
                         <filename>expat-debuginfo-2.4.1-13.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="expat-debugsource" release="13.oe2203sp4" version="2.4.1">
                         <filename>expat-debugsource-2.4.1-13.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="expat-devel" release="13.oe2203sp4" version="2.4.1">
                         <filename>expat-devel-2.4.1-13.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="expat-help" release="13.oe2203sp4" version="2.4.1">
                         <filename>expat-help-2.4.1-13.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="expat" release="13.oe2203sp4" version="2.4.1">
                         <filename>expat-2.4.1-13.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="expat-debuginfo" release="13.oe2203sp4" version="2.4.1">
                         <filename>expat-debuginfo-2.4.1-13.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="expat-debugsource" release="13.oe2203sp4" version="2.4.1">
                         <filename>expat-debugsource-2.4.1-13.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="expat-devel" release="13.oe2203sp4" version="2.4.1">
                         <filename>expat-devel-2.4.1-13.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2125</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-09-14"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48867" id="CVE-2022-48867" title="CVE-2022-48867" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48887" id="CVE-2022-48887" title="CVE-2022-48887" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-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-2024-42102" id="CVE-2024-42102" title="CVE-2024-42102" 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-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-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>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44974" id="CVE-2024-44974" title="CVE-2024-44974" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Prevent use after free on completion memoryOn driver unload any pending descriptors are flushed at thetime the interrupt is freed:idxd_dmaengine_drv_remove() -&gt;&#x9;drv_disable_wq() -&gt;&#x9;&#x9;idxd_wq_free_irq() -&gt;&#x9;&#x9;&#x9;idxd_flush_pending_descs().If there are any descriptors present that need to be flushed thisflow triggers a &#34;not present&#34; page fault as below: BUG: unable to handle page fault for address: ff391c97c70c9040 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present pageThe address that triggers the fault is the address of thedescriptor that was freed moments earlier via:drv_disable_wq()-&gt;idxd_wq_free_resources()Fix the use after free by freeing the descriptors after any possibleusage. This is done after idxd_wq_reset() to ensure that the memoryremains accessible during possible completion writes by the device.(CVE-2022-48867)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: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: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/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: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)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)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="bpftool" release="228.0.0.127.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-228.0.0.127.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="228.0.0.127.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-228.0.0.127.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="228.0.0.127.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-228.0.0.127.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="228.0.0.127.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-228.0.0.127.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="228.0.0.127.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-228.0.0.127.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="228.0.0.127.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-228.0.0.127.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="228.0.0.127.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-228.0.0.127.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="228.0.0.127.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-228.0.0.127.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="228.0.0.127.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-228.0.0.127.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="228.0.0.127.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-228.0.0.127.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="228.0.0.127.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-228.0.0.127.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="228.0.0.127.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-228.0.0.127.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="228.0.0.127.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-228.0.0.127.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="228.0.0.127.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-228.0.0.127.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="228.0.0.127.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-228.0.0.127.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="228.0.0.127.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-228.0.0.127.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="228.0.0.127.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-228.0.0.127.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="228.0.0.127.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-228.0.0.127.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="228.0.0.127.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-228.0.0.127.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="228.0.0.127.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-228.0.0.127.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="228.0.0.127.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-228.0.0.127.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="228.0.0.127.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-228.0.0.127.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="228.0.0.127.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-228.0.0.127.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="228.0.0.127.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-228.0.0.127.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="228.0.0.127.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-228.0.0.127.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="228.0.0.127.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-228.0.0.127.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="228.0.0.127.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-228.0.0.127.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="228.0.0.127.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-228.0.0.127.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="228.0.0.127.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-228.0.0.127.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="228.0.0.127.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-228.0.0.127.oe2203sp4.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-SP4</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.oe2203sp4" version="0.103.12">
                         <filename>clamav-0.103.12-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="clamav-debuginfo" release="1.oe2203sp4" version="0.103.12">
                         <filename>clamav-debuginfo-0.103.12-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="clamav-debugsource" release="1.oe2203sp4" version="0.103.12">
                         <filename>clamav-debugsource-0.103.12-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="clamav-devel" release="1.oe2203sp4" version="0.103.12">
                         <filename>clamav-devel-0.103.12-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="clamav-milter" release="1.oe2203sp4" version="0.103.12">
                         <filename>clamav-milter-0.103.12-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="clamav-update" release="1.oe2203sp4" version="0.103.12">
                         <filename>clamav-update-0.103.12-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="clamd" release="1.oe2203sp4" version="0.103.12">
                         <filename>clamd-0.103.12-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="clamav-data" release="1.oe2203sp4" version="0.103.12">
                         <filename>clamav-data-0.103.12-1.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="clamav-filesystem" release="1.oe2203sp4" version="0.103.12">
                         <filename>clamav-filesystem-0.103.12-1.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="clamav-help" release="1.oe2203sp4" version="0.103.12">
                         <filename>clamav-help-0.103.12-1.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="clamav" release="1.oe2203sp4" version="0.103.12">
                         <filename>clamav-0.103.12-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="clamav-debuginfo" release="1.oe2203sp4" version="0.103.12">
                         <filename>clamav-debuginfo-0.103.12-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="clamav-debugsource" release="1.oe2203sp4" version="0.103.12">
                         <filename>clamav-debugsource-0.103.12-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="clamav-devel" release="1.oe2203sp4" version="0.103.12">
                         <filename>clamav-devel-0.103.12-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="clamav-milter" release="1.oe2203sp4" version="0.103.12">
                         <filename>clamav-milter-0.103.12-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="clamav-update" release="1.oe2203sp4" version="0.103.12">
                         <filename>clamav-update-0.103.12-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="clamd" release="1.oe2203sp4" version="0.103.12">
                         <filename>clamd-0.103.12-1.oe2203sp4.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-SP4</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.oe2203sp4" version="0.177.0">
                         <filename>osc-0.177.0-2.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="osc-help" release="2.oe2203sp4" version="0.177.0">
                         <filename>osc-help-0.177.0-2.oe2203sp4.noarch.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-SP4</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.oe2203sp4" version="1.51.08">
                         <filename>xmlrpc-c-1.51.08-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xmlrpc-c-debuginfo" release="3.oe2203sp4" version="1.51.08">
                         <filename>xmlrpc-c-debuginfo-1.51.08-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xmlrpc-c-debugsource" release="3.oe2203sp4" version="1.51.08">
                         <filename>xmlrpc-c-debugsource-1.51.08-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xmlrpc-c-devel" release="3.oe2203sp4" version="1.51.08">
                         <filename>xmlrpc-c-devel-1.51.08-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="xmlrpc-c-help" release="3.oe2203sp4" version="1.51.08">
                         <filename>xmlrpc-c-help-1.51.08-3.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xmlrpc-c" release="3.oe2203sp4" version="1.51.08">
                         <filename>xmlrpc-c-1.51.08-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xmlrpc-c-debuginfo" release="3.oe2203sp4" version="1.51.08">
                         <filename>xmlrpc-c-debuginfo-1.51.08-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xmlrpc-c-debugsource" release="3.oe2203sp4" version="1.51.08">
                         <filename>xmlrpc-c-debugsource-1.51.08-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xmlrpc-c-devel" release="3.oe2203sp4" version="1.51.08">
                         <filename>xmlrpc-c-devel-1.51.08-3.oe2203sp4.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-SP4</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.oe2203sp4" version="20240813">
                         <filename>microcode_ctl-20240813-1.oe2203sp4.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-SP4</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.oe2203sp4" version="2.6">
                         <filename>wpa_supplicant-2.6-32.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wpa_supplicant-debuginfo" release="32.oe2203sp4" version="2.6">
                         <filename>wpa_supplicant-debuginfo-2.6-32.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wpa_supplicant-debugsource" release="32.oe2203sp4" version="2.6">
                         <filename>wpa_supplicant-debugsource-2.6-32.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wpa_supplicant-gui" release="32.oe2203sp4" version="2.6">
                         <filename>wpa_supplicant-gui-2.6-32.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wpa_supplicant-help" release="32.oe2203sp4" version="2.6">
                         <filename>wpa_supplicant-help-2.6-32.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wpa_supplicant" release="32.oe2203sp4" version="2.6">
                         <filename>wpa_supplicant-2.6-32.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wpa_supplicant-debuginfo" release="32.oe2203sp4" version="2.6">
                         <filename>wpa_supplicant-debuginfo-2.6-32.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wpa_supplicant-debugsource" release="32.oe2203sp4" version="2.6">
                         <filename>wpa_supplicant-debugsource-2.6-32.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wpa_supplicant-gui" release="32.oe2203sp4" version="2.6">
                         <filename>wpa_supplicant-gui-2.6-32.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wpa_supplicant-help" release="32.oe2203sp4" version="2.6">
                         <filename>wpa_supplicant-help-2.6-32.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2143</id>
          <title>An update for gdk-pixbuf2 is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-09-20"></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.oe2203sp4" version="2.42.6">
                         <filename>gdk-pixbuf2-2.42.6-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gdk-pixbuf2-debuginfo" release="7.oe2203sp4" version="2.42.6">
                         <filename>gdk-pixbuf2-debuginfo-2.42.6-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gdk-pixbuf2-debugsource" release="7.oe2203sp4" version="2.42.6">
                         <filename>gdk-pixbuf2-debugsource-2.42.6-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gdk-pixbuf2-devel" release="7.oe2203sp4" version="2.42.6">
                         <filename>gdk-pixbuf2-devel-2.42.6-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gdk-pixbuf2-modules" release="7.oe2203sp4" version="2.42.6">
                         <filename>gdk-pixbuf2-modules-2.42.6-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gdk-pixbuf2-tests" release="7.oe2203sp4" version="2.42.6">
                         <filename>gdk-pixbuf2-tests-2.42.6-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="gdk-pixbuf2-help" release="7.oe2203sp4" version="2.42.6">
                         <filename>gdk-pixbuf2-help-2.42.6-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gdk-pixbuf2" release="7.oe2203sp4" version="2.42.6">
                         <filename>gdk-pixbuf2-2.42.6-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gdk-pixbuf2-debuginfo" release="7.oe2203sp4" version="2.42.6">
                         <filename>gdk-pixbuf2-debuginfo-2.42.6-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gdk-pixbuf2-debugsource" release="7.oe2203sp4" version="2.42.6">
                         <filename>gdk-pixbuf2-debugsource-2.42.6-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gdk-pixbuf2-devel" release="7.oe2203sp4" version="2.42.6">
                         <filename>gdk-pixbuf2-devel-2.42.6-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gdk-pixbuf2-modules" release="7.oe2203sp4" version="2.42.6">
                         <filename>gdk-pixbuf2-modules-2.42.6-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gdk-pixbuf2-tests" release="7.oe2203sp4" version="2.42.6">
                         <filename>gdk-pixbuf2-tests-2.42.6-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2148</id>
          <title>An update for fence-agents is now available for openEuler-22.03-LTS-SP4</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="36.oe2203sp4" version="4.2.1">
                         <filename>fence-agents-all-4.2.1-36.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="fence-agents-debuginfo" release="36.oe2203sp4" version="4.2.1">
                         <filename>fence-agents-debuginfo-4.2.1-36.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="fence-agents-debugsource" release="36.oe2203sp4" version="4.2.1">
                         <filename>fence-agents-debugsource-4.2.1-36.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="fence-agents-kdump" release="36.oe2203sp4" version="4.2.1">
                         <filename>fence-agents-kdump-4.2.1-36.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="fence-agents-redfish" release="36.oe2203sp4" version="4.2.1">
                         <filename>fence-agents-redfish-4.2.1-36.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-amt-ws" release="36.oe2203sp4" version="4.2.1">
                         <filename>fence-agents-amt-ws-4.2.1-36.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-apc" release="36.oe2203sp4" version="4.2.1">
                         <filename>fence-agents-apc-4.2.1-36.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-apc-snmp" release="36.oe2203sp4" version="4.2.1">
                         <filename>fence-agents-apc-snmp-4.2.1-36.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-aws" release="36.oe2203sp4" version="4.2.1">
                         <filename>fence-agents-aws-4.2.1-36.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-bladecenter" release="36.oe2203sp4" version="4.2.1">
                         <filename>fence-agents-bladecenter-4.2.1-36.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-brocade" release="36.oe2203sp4" version="4.2.1">
                         <filename>fence-agents-brocade-4.2.1-36.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-cisco-mds" release="36.oe2203sp4" version="4.2.1">
                         <filename>fence-agents-cisco-mds-4.2.1-36.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-cisco-ucs" release="36.oe2203sp4" version="4.2.1">
                         <filename>fence-agents-cisco-ucs-4.2.1-36.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-common" release="36.oe2203sp4" version="4.2.1">
                         <filename>fence-agents-common-4.2.1-36.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-compute" release="36.oe2203sp4" version="4.2.1">
                         <filename>fence-agents-compute-4.2.1-36.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-drac5" release="36.oe2203sp4" version="4.2.1">
                         <filename>fence-agents-drac5-4.2.1-36.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-eaton-snmp" release="36.oe2203sp4" version="4.2.1">
                         <filename>fence-agents-eaton-snmp-4.2.1-36.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-emerson" release="36.oe2203sp4" version="4.2.1">
                         <filename>fence-agents-emerson-4.2.1-36.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-eps" release="36.oe2203sp4" version="4.2.1">
                         <filename>fence-agents-eps-4.2.1-36.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-gce" release="36.oe2203sp4" version="4.2.1">
                         <filename>fence-agents-gce-4.2.1-36.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-heuristics-ping" release="36.oe2203sp4" version="4.2.1">
                         <filename>fence-agents-heuristics-ping-4.2.1-36.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-hpblade" release="36.oe2203sp4" version="4.2.1">
                         <filename>fence-agents-hpblade-4.2.1-36.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-ibmblade" release="36.oe2203sp4" version="4.2.1">
                         <filename>fence-agents-ibmblade-4.2.1-36.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-ifmib" release="36.oe2203sp4" version="4.2.1">
                         <filename>fence-agents-ifmib-4.2.1-36.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-ilo-moonshot" release="36.oe2203sp4" version="4.2.1">
                         <filename>fence-agents-ilo-moonshot-4.2.1-36.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-ilo-mp" release="36.oe2203sp4" version="4.2.1">
                         <filename>fence-agents-ilo-mp-4.2.1-36.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-ilo-ssh" release="36.oe2203sp4" version="4.2.1">
                         <filename>fence-agents-ilo-ssh-4.2.1-36.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-ilo2" release="36.oe2203sp4" version="4.2.1">
                         <filename>fence-agents-ilo2-4.2.1-36.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-intelmodular" release="36.oe2203sp4" version="4.2.1">
                         <filename>fence-agents-intelmodular-4.2.1-36.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-ipdu" release="36.oe2203sp4" version="4.2.1">
                         <filename>fence-agents-ipdu-4.2.1-36.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-ipmilan" release="36.oe2203sp4" version="4.2.1">
                         <filename>fence-agents-ipmilan-4.2.1-36.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-mpath" release="36.oe2203sp4" version="4.2.1">
                         <filename>fence-agents-mpath-4.2.1-36.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-rhevm" release="36.oe2203sp4" version="4.2.1">
                         <filename>fence-agents-rhevm-4.2.1-36.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-rsa" release="36.oe2203sp4" version="4.2.1">
                         <filename>fence-agents-rsa-4.2.1-36.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-rsb" release="36.oe2203sp4" version="4.2.1">
                         <filename>fence-agents-rsb-4.2.1-36.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-sbd" release="36.oe2203sp4" version="4.2.1">
                         <filename>fence-agents-sbd-4.2.1-36.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-scsi" release="36.oe2203sp4" version="4.2.1">
                         <filename>fence-agents-scsi-4.2.1-36.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-virsh" release="36.oe2203sp4" version="4.2.1">
                         <filename>fence-agents-virsh-4.2.1-36.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-vmware-rest" release="36.oe2203sp4" version="4.2.1">
                         <filename>fence-agents-vmware-rest-4.2.1-36.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-vmware-soap" release="36.oe2203sp4" version="4.2.1">
                         <filename>fence-agents-vmware-soap-4.2.1-36.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-wti" release="36.oe2203sp4" version="4.2.1">
                         <filename>fence-agents-wti-4.2.1-36.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="fence-agents-aliyun" release="36.oe2203sp4" version="4.2.1">
                         <filename>fence-agents-aliyun-4.2.1-36.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="fence-agents-all" release="36.oe2203sp4" version="4.2.1">
                         <filename>fence-agents-all-4.2.1-36.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="fence-agents-debuginfo" release="36.oe2203sp4" version="4.2.1">
                         <filename>fence-agents-debuginfo-4.2.1-36.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="fence-agents-debugsource" release="36.oe2203sp4" version="4.2.1">
                         <filename>fence-agents-debugsource-4.2.1-36.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="fence-agents-kdump" release="36.oe2203sp4" version="4.2.1">
                         <filename>fence-agents-kdump-4.2.1-36.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="fence-agents-redfish" release="36.oe2203sp4" version="4.2.1">
                         <filename>fence-agents-redfish-4.2.1-36.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2150</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-09-20"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52916" id="CVE-2023-52916" title="CVE-2023-52916" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43829" id="CVE-2024-43829" title="CVE-2024-43829" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-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: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: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="bpftool" release="229.0.0.128.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-229.0.0.128.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="229.0.0.128.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-229.0.0.128.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="229.0.0.128.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-229.0.0.128.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="229.0.0.128.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-229.0.0.128.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="229.0.0.128.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-229.0.0.128.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="229.0.0.128.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-229.0.0.128.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="229.0.0.128.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-229.0.0.128.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="229.0.0.128.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-229.0.0.128.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="229.0.0.128.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-229.0.0.128.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="229.0.0.128.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-229.0.0.128.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="229.0.0.128.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-229.0.0.128.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="229.0.0.128.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-229.0.0.128.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="229.0.0.128.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-229.0.0.128.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="229.0.0.128.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-229.0.0.128.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="229.0.0.128.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-229.0.0.128.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="229.0.0.128.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-229.0.0.128.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="229.0.0.128.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-229.0.0.128.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="229.0.0.128.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-229.0.0.128.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="229.0.0.128.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-229.0.0.128.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="229.0.0.128.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-229.0.0.128.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="229.0.0.128.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-229.0.0.128.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="229.0.0.128.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-229.0.0.128.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="229.0.0.128.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-229.0.0.128.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="229.0.0.128.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-229.0.0.128.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="229.0.0.128.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-229.0.0.128.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="229.0.0.128.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-229.0.0.128.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="229.0.0.128.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-229.0.0.128.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="229.0.0.128.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-229.0.0.128.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="229.0.0.128.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-229.0.0.128.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="229.0.0.128.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-229.0.0.128.oe2203sp4.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-SP4</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.oe2203sp4" version="1.0.79">
                         <filename>scsi-target-utils-1.0.79-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="scsi-target-utils-debuginfo" release="6.oe2203sp4" version="1.0.79">
                         <filename>scsi-target-utils-debuginfo-1.0.79-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="scsi-target-utils-debugsource" release="6.oe2203sp4" version="1.0.79">
                         <filename>scsi-target-utils-debugsource-1.0.79-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="scsi-target-utils-gluster" release="6.oe2203sp4" version="1.0.79">
                         <filename>scsi-target-utils-gluster-1.0.79-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="scsi-target-utils-rbd" release="6.oe2203sp4" version="1.0.79">
                         <filename>scsi-target-utils-rbd-1.0.79-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="scsi-target-utils-help" release="6.oe2203sp4" version="1.0.79">
                         <filename>scsi-target-utils-help-1.0.79-6.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="scsi-target-utils" release="6.oe2203sp4" version="1.0.79">
                         <filename>scsi-target-utils-1.0.79-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="scsi-target-utils-debuginfo" release="6.oe2203sp4" version="1.0.79">
                         <filename>scsi-target-utils-debuginfo-1.0.79-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="scsi-target-utils-debugsource" release="6.oe2203sp4" version="1.0.79">
                         <filename>scsi-target-utils-debugsource-1.0.79-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="scsi-target-utils-gluster" release="6.oe2203sp4" version="1.0.79">
                         <filename>scsi-target-utils-gluster-1.0.79-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="scsi-target-utils-rbd" release="6.oe2203sp4" version="1.0.79">
                         <filename>scsi-target-utils-rbd-1.0.79-6.oe2203sp4.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-SP4</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.oe2203sp4" version="20240910">
                         <filename>microcode_ctl-20240910-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2161</id>
          <title>An update for ghostscript is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Low</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>
          </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)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="ghostscript" release="11.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-9.55.0-11.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ghostscript-debuginfo" release="11.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-debuginfo-9.55.0-11.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ghostscript-debugsource" release="11.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-debugsource-9.55.0-11.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ghostscript-devel" release="11.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-devel-9.55.0-11.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ghostscript-tools-dvipdf" release="11.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-tools-dvipdf-9.55.0-11.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="ghostscript-help" release="11.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-help-9.55.0-11.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript" release="11.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-9.55.0-11.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript-debuginfo" release="11.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-debuginfo-9.55.0-11.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript-debugsource" release="11.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-debugsource-9.55.0-11.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript-devel" release="11.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-devel-9.55.0-11.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript-tools-dvipdf" release="11.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-tools-dvipdf-9.55.0-11.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2167</id>
          <title>An update for three-eight-nine-ds-base is now available for openEuler-22.03-LTS-SP4</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.oe2203sp4" version="1.4.3.36">
                         <filename>389-ds-base-1.4.3.36-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="389-ds-base-debuginfo" release="7.oe2203sp4" version="1.4.3.36">
                         <filename>389-ds-base-debuginfo-1.4.3.36-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="389-ds-base-debugsource" release="7.oe2203sp4" version="1.4.3.36">
                         <filename>389-ds-base-debugsource-1.4.3.36-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="389-ds-base-devel" release="7.oe2203sp4" version="1.4.3.36">
                         <filename>389-ds-base-devel-1.4.3.36-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="389-ds-base-help" release="7.oe2203sp4" version="1.4.3.36">
                         <filename>389-ds-base-help-1.4.3.36-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="389-ds-base-legacy-tools" release="7.oe2203sp4" version="1.4.3.36">
                         <filename>389-ds-base-legacy-tools-1.4.3.36-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="389-ds-base-snmp" release="7.oe2203sp4" version="1.4.3.36">
                         <filename>389-ds-base-snmp-1.4.3.36-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="cockpit-389-ds" release="7.oe2203sp4" version="1.4.3.36">
                         <filename>cockpit-389-ds-1.4.3.36-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-lib389" release="7.oe2203sp4" version="1.4.3.36">
                         <filename>python3-lib389-1.4.3.36-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="389-ds-base" release="7.oe2203sp4" version="1.4.3.36">
                         <filename>389-ds-base-1.4.3.36-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="389-ds-base-debuginfo" release="7.oe2203sp4" version="1.4.3.36">
                         <filename>389-ds-base-debuginfo-1.4.3.36-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="389-ds-base-debugsource" release="7.oe2203sp4" version="1.4.3.36">
                         <filename>389-ds-base-debugsource-1.4.3.36-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="389-ds-base-devel" release="7.oe2203sp4" version="1.4.3.36">
                         <filename>389-ds-base-devel-1.4.3.36-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="389-ds-base-help" release="7.oe2203sp4" version="1.4.3.36">
                         <filename>389-ds-base-help-1.4.3.36-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="389-ds-base-legacy-tools" release="7.oe2203sp4" version="1.4.3.36">
                         <filename>389-ds-base-legacy-tools-1.4.3.36-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="389-ds-base-snmp" release="7.oe2203sp4" version="1.4.3.36">
                         <filename>389-ds-base-snmp-1.4.3.36-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2175</id>
          <title>An update for nodejs is now available for openEuler-22.03-LTS-SP4</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.oe2203sp4" version="12.22.11">
                         <filename>nodejs-12.22.11-10.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nodejs-debuginfo" release="10.oe2203sp4" version="12.22.11">
                         <filename>nodejs-debuginfo-12.22.11-10.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nodejs-debugsource" release="10.oe2203sp4" version="12.22.11">
                         <filename>nodejs-debugsource-12.22.11-10.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nodejs-devel" release="10.oe2203sp4" version="12.22.11">
                         <filename>nodejs-devel-12.22.11-10.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nodejs-full-i18n" release="10.oe2203sp4" version="12.22.11">
                         <filename>nodejs-full-i18n-12.22.11-10.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nodejs-libs" release="10.oe2203sp4" version="12.22.11">
                         <filename>nodejs-libs-12.22.11-10.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="npm" release="1.12.22.11.10.oe2203sp4" version="6.14.16">
                         <filename>npm-6.14.16-1.12.22.11.10.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="v8-devel" release="1.12.22.11.10.oe2203sp4" version="7.8.279.23">
                         <filename>v8-devel-7.8.279.23-1.12.22.11.10.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="nodejs-docs" release="10.oe2203sp4" version="12.22.11">
                         <filename>nodejs-docs-12.22.11-10.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nodejs" release="10.oe2203sp4" version="12.22.11">
                         <filename>nodejs-12.22.11-10.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nodejs-debuginfo" release="10.oe2203sp4" version="12.22.11">
                         <filename>nodejs-debuginfo-12.22.11-10.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nodejs-debugsource" release="10.oe2203sp4" version="12.22.11">
                         <filename>nodejs-debugsource-12.22.11-10.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nodejs-devel" release="10.oe2203sp4" version="12.22.11">
                         <filename>nodejs-devel-12.22.11-10.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nodejs-full-i18n" release="10.oe2203sp4" version="12.22.11">
                         <filename>nodejs-full-i18n-12.22.11-10.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nodejs-libs" release="10.oe2203sp4" version="12.22.11">
                         <filename>nodejs-libs-12.22.11-10.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="npm" release="1.12.22.11.10.oe2203sp4" version="6.14.16">
                         <filename>npm-6.14.16-1.12.22.11.10.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="v8-devel" release="1.12.22.11.10.oe2203sp4" version="7.8.279.23">
                         <filename>v8-devel-7.8.279.23-1.12.22.11.10.oe2203sp4.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-SP4</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="2.oe2203sp4" version="1.10.3">
                         <filename>libpcap-1.10.3-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="14" arch="aarch64" name="libpcap-debuginfo" release="2.oe2203sp4" version="1.10.3">
                         <filename>libpcap-debuginfo-1.10.3-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="14" arch="aarch64" name="libpcap-debugsource" release="2.oe2203sp4" version="1.10.3">
                         <filename>libpcap-debugsource-1.10.3-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="14" arch="aarch64" name="libpcap-devel" release="2.oe2203sp4" version="1.10.3">
                         <filename>libpcap-devel-1.10.3-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="14" arch="noarch" name="libpcap-help" release="2.oe2203sp4" version="1.10.3">
                         <filename>libpcap-help-1.10.3-2.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="14" arch="x86_64" name="libpcap" release="2.oe2203sp4" version="1.10.3">
                         <filename>libpcap-1.10.3-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="14" arch="x86_64" name="libpcap-debuginfo" release="2.oe2203sp4" version="1.10.3">
                         <filename>libpcap-debuginfo-1.10.3-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="14" arch="x86_64" name="libpcap-debugsource" release="2.oe2203sp4" version="1.10.3">
                         <filename>libpcap-debugsource-1.10.3-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="14" arch="x86_64" name="libpcap-devel" release="2.oe2203sp4" version="1.10.3">
                         <filename>libpcap-devel-1.10.3-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2182</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-09-27"></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-48828" id="CVE-2022-48828" title="CVE-2022-48828" 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-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-40980" id="CVE-2024-40980" title="CVE-2024-40980" 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-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-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-44939" id="CVE-2024-44939" title="CVE-2024-44939" 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-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-45025" id="CVE-2024-45025" title="CVE-2024-45025" 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-46742" id="CVE-2024-46742" title="CVE-2024-46742" 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>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46800" id="CVE-2024-46800" title="CVE-2024-46800" 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: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: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: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: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: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: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: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: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: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: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: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: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: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: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)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)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="bpftool" release="230.0.0.129.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-230.0.0.129.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="230.0.0.129.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-230.0.0.129.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="230.0.0.129.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-230.0.0.129.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="230.0.0.129.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-230.0.0.129.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="230.0.0.129.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-230.0.0.129.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="230.0.0.129.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-230.0.0.129.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="230.0.0.129.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-230.0.0.129.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="230.0.0.129.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-230.0.0.129.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="230.0.0.129.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-230.0.0.129.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="230.0.0.129.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-230.0.0.129.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="230.0.0.129.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-230.0.0.129.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="230.0.0.129.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-230.0.0.129.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="230.0.0.129.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-230.0.0.129.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="230.0.0.129.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-230.0.0.129.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="230.0.0.129.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-230.0.0.129.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="230.0.0.129.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-230.0.0.129.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="230.0.0.129.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-230.0.0.129.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="230.0.0.129.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-230.0.0.129.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="230.0.0.129.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-230.0.0.129.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="230.0.0.129.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-230.0.0.129.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="230.0.0.129.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-230.0.0.129.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="230.0.0.129.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-230.0.0.129.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="230.0.0.129.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-230.0.0.129.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="230.0.0.129.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-230.0.0.129.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="230.0.0.129.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-230.0.0.129.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="230.0.0.129.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-230.0.0.129.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="230.0.0.129.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-230.0.0.129.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="230.0.0.129.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-230.0.0.129.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="230.0.0.129.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-230.0.0.129.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="230.0.0.129.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-230.0.0.129.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2189</id>
          <title>An update for uboot-tools is now available for openEuler-22.03-LTS-SP4</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.oe2203sp4" version="2021.10">
                         <filename>uboot-images-elf-2021.10-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="uboot-tools" release="8.oe2203sp4" version="2021.10">
                         <filename>uboot-tools-2021.10-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="uboot-tools-debuginfo" release="8.oe2203sp4" version="2021.10">
                         <filename>uboot-tools-debuginfo-2021.10-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="uboot-tools-debugsource" release="8.oe2203sp4" version="2021.10">
                         <filename>uboot-tools-debugsource-2021.10-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="uboot-images-armv8" release="8.oe2203sp4" version="2021.10">
                         <filename>uboot-images-armv8-2021.10-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="uboot-tools-help" release="8.oe2203sp4" version="2021.10">
                         <filename>uboot-tools-help-2021.10-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="uboot-tools" release="8.oe2203sp4" version="2021.10">
                         <filename>uboot-tools-2021.10-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="uboot-tools-debuginfo" release="8.oe2203sp4" version="2021.10">
                         <filename>uboot-tools-debuginfo-2021.10-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="uboot-tools-debugsource" release="8.oe2203sp4" version="2021.10">
                         <filename>uboot-tools-debugsource-2021.10-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2190</id>
          <title>An update for python3 is now available for openEuler-22.03-LTS-SP4</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-0450" id="CVE-2024-0450" title="CVE-2024-0450" 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)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)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="36.oe2203sp4" version="3.9.9">
                         <filename>python3-3.9.9-36.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-debug" release="36.oe2203sp4" version="3.9.9">
                         <filename>python3-debug-3.9.9-36.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-debuginfo" release="36.oe2203sp4" version="3.9.9">
                         <filename>python3-debuginfo-3.9.9-36.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-debugsource" release="36.oe2203sp4" version="3.9.9">
                         <filename>python3-debugsource-3.9.9-36.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-devel" release="36.oe2203sp4" version="3.9.9">
                         <filename>python3-devel-3.9.9-36.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-unversioned-command" release="36.oe2203sp4" version="3.9.9">
                         <filename>python3-unversioned-command-3.9.9-36.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-help" release="36.oe2203sp4" version="3.9.9">
                         <filename>python3-help-3.9.9-36.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3" release="36.oe2203sp4" version="3.9.9">
                         <filename>python3-3.9.9-36.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-debug" release="36.oe2203sp4" version="3.9.9">
                         <filename>python3-debug-3.9.9-36.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-debuginfo" release="36.oe2203sp4" version="3.9.9">
                         <filename>python3-debuginfo-3.9.9-36.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-debugsource" release="36.oe2203sp4" version="3.9.9">
                         <filename>python3-debugsource-3.9.9-36.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-devel" release="36.oe2203sp4" version="3.9.9">
                         <filename>python3-devel-3.9.9-36.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-unversioned-command" release="36.oe2203sp4" version="3.9.9">
                         <filename>python3-unversioned-command-3.9.9-36.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2195</id>
          <title>An update for assimp is now available for openEuler-22.03-LTS-SP4</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.oe2203sp4" version="5.2.4">
                         <filename>assimp-5.2.4-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="assimp-debuginfo" release="3.oe2203sp4" version="5.2.4">
                         <filename>assimp-debuginfo-5.2.4-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="assimp-debugsource" release="3.oe2203sp4" version="5.2.4">
                         <filename>assimp-debugsource-5.2.4-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="assimp-devel" release="3.oe2203sp4" version="5.2.4">
                         <filename>assimp-devel-5.2.4-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="assimp-help" release="3.oe2203sp4" version="5.2.4">
                         <filename>assimp-help-5.2.4-3.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-assimp" release="3.oe2203sp4" version="5.2.4">
                         <filename>python3-assimp-5.2.4-3.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="assimp" release="3.oe2203sp4" version="5.2.4">
                         <filename>assimp-5.2.4-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="assimp-debuginfo" release="3.oe2203sp4" version="5.2.4">
                         <filename>assimp-debuginfo-5.2.4-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="assimp-debugsource" release="3.oe2203sp4" version="5.2.4">
                         <filename>assimp-debugsource-5.2.4-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="assimp-devel" release="3.oe2203sp4" version="5.2.4">
                         <filename>assimp-devel-5.2.4-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2200</id>
          <title>An update for qemu is now available for openEuler-22.03-LTS-SP4</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.oe2203sp4" version="6.2.0">
                         <filename>qemu-6.2.0-99.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-curl" release="99.oe2203sp4" version="6.2.0">
                         <filename>qemu-block-curl-6.2.0-99.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-iscsi" release="99.oe2203sp4" version="6.2.0">
                         <filename>qemu-block-iscsi-6.2.0-99.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-rbd" release="99.oe2203sp4" version="6.2.0">
                         <filename>qemu-block-rbd-6.2.0-99.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-ssh" release="99.oe2203sp4" version="6.2.0">
                         <filename>qemu-block-ssh-6.2.0-99.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-debuginfo" release="99.oe2203sp4" version="6.2.0">
                         <filename>qemu-debuginfo-6.2.0-99.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-debugsource" release="99.oe2203sp4" version="6.2.0">
                         <filename>qemu-debugsource-6.2.0-99.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-guest-agent" release="99.oe2203sp4" version="6.2.0">
                         <filename>qemu-guest-agent-6.2.0-99.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-hw-usb-host" release="99.oe2203sp4" version="6.2.0">
                         <filename>qemu-hw-usb-host-6.2.0-99.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-img" release="99.oe2203sp4" version="6.2.0">
                         <filename>qemu-img-6.2.0-99.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-aarch64" release="99.oe2203sp4" version="6.2.0">
                         <filename>qemu-system-aarch64-6.2.0-99.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-arm" release="99.oe2203sp4" version="6.2.0">
                         <filename>qemu-system-arm-6.2.0-99.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-riscv" release="99.oe2203sp4" version="6.2.0">
                         <filename>qemu-system-riscv-6.2.0-99.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-x86_64" release="99.oe2203sp4" version="6.2.0">
                         <filename>qemu-system-x86_64-6.2.0-99.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="noarch" name="qemu-help" release="99.oe2203sp4" version="6.2.0">
                         <filename>qemu-help-6.2.0-99.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu" release="99.oe2203sp4" version="6.2.0">
                         <filename>qemu-6.2.0-99.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-curl" release="99.oe2203sp4" version="6.2.0">
                         <filename>qemu-block-curl-6.2.0-99.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-iscsi" release="99.oe2203sp4" version="6.2.0">
                         <filename>qemu-block-iscsi-6.2.0-99.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-rbd" release="99.oe2203sp4" version="6.2.0">
                         <filename>qemu-block-rbd-6.2.0-99.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-ssh" release="99.oe2203sp4" version="6.2.0">
                         <filename>qemu-block-ssh-6.2.0-99.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-debuginfo" release="99.oe2203sp4" version="6.2.0">
                         <filename>qemu-debuginfo-6.2.0-99.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-debugsource" release="99.oe2203sp4" version="6.2.0">
                         <filename>qemu-debugsource-6.2.0-99.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-guest-agent" release="99.oe2203sp4" version="6.2.0">
                         <filename>qemu-guest-agent-6.2.0-99.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-hw-usb-host" release="99.oe2203sp4" version="6.2.0">
                         <filename>qemu-hw-usb-host-6.2.0-99.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-img" release="99.oe2203sp4" version="6.2.0">
                         <filename>qemu-img-6.2.0-99.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-seabios" release="99.oe2203sp4" version="6.2.0">
                         <filename>qemu-seabios-6.2.0-99.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-aarch64" release="99.oe2203sp4" version="6.2.0">
                         <filename>qemu-system-aarch64-6.2.0-99.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-arm" release="99.oe2203sp4" version="6.2.0">
                         <filename>qemu-system-arm-6.2.0-99.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-riscv" release="99.oe2203sp4" version="6.2.0">
                         <filename>qemu-system-riscv-6.2.0-99.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-x86_64" release="99.oe2203sp4" version="6.2.0">
                         <filename>qemu-system-x86_64-6.2.0-99.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2204</id>
          <title>An update for ffmpeg is now available for openEuler-22.03-LTS-SP4</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.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-4.2.4-18.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ffmpeg-debuginfo" release="18.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-debuginfo-4.2.4-18.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ffmpeg-debugsource" release="18.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-debugsource-4.2.4-18.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ffmpeg-devel" release="18.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-devel-4.2.4-18.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ffmpeg-libs" release="18.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-libs-4.2.4-18.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libavdevice" release="18.oe2203sp4" version="4.2.4">
                         <filename>libavdevice-4.2.4-18.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg" release="18.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-4.2.4-18.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg-debuginfo" release="18.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-debuginfo-4.2.4-18.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg-debugsource" release="18.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-debugsource-4.2.4-18.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg-devel" release="18.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-devel-4.2.4-18.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg-libs" release="18.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-libs-4.2.4-18.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libavdevice" release="18.oe2203sp4" version="4.2.4">
                         <filename>libavdevice-4.2.4-18.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2207</id>
          <title>An update for squid is now available for openEuler-22.03-LTS-SP4</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.oe2203sp4" version="4.9">
                         <filename>squid-4.9-26.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="squid-debuginfo" release="26.oe2203sp4" version="4.9">
                         <filename>squid-debuginfo-4.9-26.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="squid-debugsource" release="26.oe2203sp4" version="4.9">
                         <filename>squid-debugsource-4.9-26.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="squid" release="26.oe2203sp4" version="4.9">
                         <filename>squid-4.9-26.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="squid-debuginfo" release="26.oe2203sp4" version="4.9">
                         <filename>squid-debuginfo-4.9-26.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="squid-debugsource" release="26.oe2203sp4" version="4.9">
                         <filename>squid-debugsource-4.9-26.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2210</id>
          <title>An update for poppler is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2024-09-27"></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.oe2203sp4" version="0.90.0">
                         <filename>poppler-0.90.0-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-cpp" release="9.oe2203sp4" version="0.90.0">
                         <filename>poppler-cpp-0.90.0-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-cpp-devel" release="9.oe2203sp4" version="0.90.0">
                         <filename>poppler-cpp-devel-0.90.0-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-debuginfo" release="9.oe2203sp4" version="0.90.0">
                         <filename>poppler-debuginfo-0.90.0-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-debugsource" release="9.oe2203sp4" version="0.90.0">
                         <filename>poppler-debugsource-0.90.0-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-devel" release="9.oe2203sp4" version="0.90.0">
                         <filename>poppler-devel-0.90.0-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-glib" release="9.oe2203sp4" version="0.90.0">
                         <filename>poppler-glib-0.90.0-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-glib-devel" release="9.oe2203sp4" version="0.90.0">
                         <filename>poppler-glib-devel-0.90.0-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-qt5" release="9.oe2203sp4" version="0.90.0">
                         <filename>poppler-qt5-0.90.0-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-qt5-devel" release="9.oe2203sp4" version="0.90.0">
                         <filename>poppler-qt5-devel-0.90.0-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-utils" release="9.oe2203sp4" version="0.90.0">
                         <filename>poppler-utils-0.90.0-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="poppler-glib-doc" release="9.oe2203sp4" version="0.90.0">
                         <filename>poppler-glib-doc-0.90.0-9.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="poppler-help" release="9.oe2203sp4" version="0.90.0">
                         <filename>poppler-help-0.90.0-9.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler" release="9.oe2203sp4" version="0.90.0">
                         <filename>poppler-0.90.0-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-cpp" release="9.oe2203sp4" version="0.90.0">
                         <filename>poppler-cpp-0.90.0-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-cpp-devel" release="9.oe2203sp4" version="0.90.0">
                         <filename>poppler-cpp-devel-0.90.0-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-debuginfo" release="9.oe2203sp4" version="0.90.0">
                         <filename>poppler-debuginfo-0.90.0-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-debugsource" release="9.oe2203sp4" version="0.90.0">
                         <filename>poppler-debugsource-0.90.0-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-devel" release="9.oe2203sp4" version="0.90.0">
                         <filename>poppler-devel-0.90.0-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-glib" release="9.oe2203sp4" version="0.90.0">
                         <filename>poppler-glib-0.90.0-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-glib-devel" release="9.oe2203sp4" version="0.90.0">
                         <filename>poppler-glib-devel-0.90.0-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-qt5" release="9.oe2203sp4" version="0.90.0">
                         <filename>poppler-qt5-0.90.0-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-qt5-devel" release="9.oe2203sp4" version="0.90.0">
                         <filename>poppler-qt5-devel-0.90.0-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-utils" release="9.oe2203sp4" version="0.90.0">
                         <filename>poppler-utils-0.90.0-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2220</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-10-12"></issued>
          <references>
               <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-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-43900" id="CVE-2024-43900" title="CVE-2024-43900" 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-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-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-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-46833" id="CVE-2024-46833" title="CVE-2024-46833" 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: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: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: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: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: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: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: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:net: hns3: void array out of bound when loop tnl_numWhen query reg inf of SSU, it loops tnl_num times. However, tnl_num comesfrom hardware and the length of array is a fixed value. To void array outof bound, make sure the loop time is not greater than the length of array(CVE-2024-46833)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="bpftool" release="231.0.0.130.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="231.0.0.130.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="231.0.0.130.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="231.0.0.130.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="231.0.0.130.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="231.0.0.130.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="231.0.0.130.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="231.0.0.130.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="231.0.0.130.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="231.0.0.130.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="231.0.0.130.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="231.0.0.130.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="231.0.0.130.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="231.0.0.130.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="231.0.0.130.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="231.0.0.130.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="231.0.0.130.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="231.0.0.130.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="231.0.0.130.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="231.0.0.130.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="231.0.0.130.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="231.0.0.130.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="231.0.0.130.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="231.0.0.130.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="231.0.0.130.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="231.0.0.130.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="231.0.0.130.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="231.0.0.130.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="231.0.0.130.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="231.0.0.130.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-231.0.0.130.oe2203sp4.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-SP4</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.oe2203sp4" version="1.14.47">
                         <filename>libgsf-1.14.47-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libgsf-debuginfo" release="2.oe2203sp4" version="1.14.47">
                         <filename>libgsf-debuginfo-1.14.47-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libgsf-debugsource" release="2.oe2203sp4" version="1.14.47">
                         <filename>libgsf-debugsource-1.14.47-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libgsf-devel" release="2.oe2203sp4" version="1.14.47">
                         <filename>libgsf-devel-1.14.47-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libgsf-help" release="2.oe2203sp4" version="1.14.47">
                         <filename>libgsf-help-1.14.47-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libgsf" release="2.oe2203sp4" version="1.14.47">
                         <filename>libgsf-1.14.47-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libgsf-debuginfo" release="2.oe2203sp4" version="1.14.47">
                         <filename>libgsf-debuginfo-1.14.47-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libgsf-debugsource" release="2.oe2203sp4" version="1.14.47">
                         <filename>libgsf-debugsource-1.14.47-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libgsf-devel" release="2.oe2203sp4" version="1.14.47">
                         <filename>libgsf-devel-1.14.47-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libgsf-help" release="2.oe2203sp4" version="1.14.47">
                         <filename>libgsf-help-1.14.47-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2225</id>
          <title>An update for cups is now available for openEuler-22.03-LTS-SP4</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.oe2203sp4" version="2.4.0">
                         <filename>cups-2.4.0-13.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="cups-client" release="13.oe2203sp4" version="2.4.0">
                         <filename>cups-client-2.4.0-13.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="cups-debuginfo" release="13.oe2203sp4" version="2.4.0">
                         <filename>cups-debuginfo-2.4.0-13.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="cups-debugsource" release="13.oe2203sp4" version="2.4.0">
                         <filename>cups-debugsource-2.4.0-13.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="cups-devel" release="13.oe2203sp4" version="2.4.0">
                         <filename>cups-devel-2.4.0-13.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="cups-ipptool" release="13.oe2203sp4" version="2.4.0">
                         <filename>cups-ipptool-2.4.0-13.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="cups-libs" release="13.oe2203sp4" version="2.4.0">
                         <filename>cups-libs-2.4.0-13.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="cups-lpd" release="13.oe2203sp4" version="2.4.0">
                         <filename>cups-lpd-2.4.0-13.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="cups-printerapp" release="13.oe2203sp4" version="2.4.0">
                         <filename>cups-printerapp-2.4.0-13.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="cups-filesystem" release="13.oe2203sp4" version="2.4.0">
                         <filename>cups-filesystem-2.4.0-13.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="cups-help" release="13.oe2203sp4" version="2.4.0">
                         <filename>cups-help-2.4.0-13.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="cups" release="13.oe2203sp4" version="2.4.0">
                         <filename>cups-2.4.0-13.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="cups-client" release="13.oe2203sp4" version="2.4.0">
                         <filename>cups-client-2.4.0-13.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="cups-debuginfo" release="13.oe2203sp4" version="2.4.0">
                         <filename>cups-debuginfo-2.4.0-13.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="cups-debugsource" release="13.oe2203sp4" version="2.4.0">
                         <filename>cups-debugsource-2.4.0-13.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="cups-devel" release="13.oe2203sp4" version="2.4.0">
                         <filename>cups-devel-2.4.0-13.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="cups-ipptool" release="13.oe2203sp4" version="2.4.0">
                         <filename>cups-ipptool-2.4.0-13.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="cups-libs" release="13.oe2203sp4" version="2.4.0">
                         <filename>cups-libs-2.4.0-13.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="cups-lpd" release="13.oe2203sp4" version="2.4.0">
                         <filename>cups-lpd-2.4.0-13.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="cups-printerapp" release="13.oe2203sp4" version="2.4.0">
                         <filename>cups-printerapp-2.4.0-13.oe2203sp4.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-SP4</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.oe2203sp4" version="1.7.0">
                         <filename>rubygem-webrick-1.7.0-2.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-webrick-help" release="2.oe2203sp4" version="1.7.0">
                         <filename>rubygem-webrick-help-1.7.0-2.oe2203sp4.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-SP4</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.oe2203sp4" version="1.10.2">
                         <filename>avro-1.10.2-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avro" release="6.oe2203sp4" version="1.10.2">
                         <filename>avro-1.10.2-6.oe2203sp4.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-SP4</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.oe2203sp4" version="2.4">
                         <filename>jenkins-json-lib-2.4-23.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="json-lib" release="23.oe2203sp4" version="2.4">
                         <filename>json-lib-2.4-23.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="json-lib-help" release="23.oe2203sp4" version="2.4">
                         <filename>json-lib-help-2.4-23.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2231</id>
          <title>An update for unbound is now available for openEuler-22.03-LTS-SP4</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="15.oe2203sp4" version="1.13.2">
                         <filename>python3-unbound-1.13.2-15.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="unbound" release="15.oe2203sp4" version="1.13.2">
                         <filename>unbound-1.13.2-15.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="unbound-anchor" release="15.oe2203sp4" version="1.13.2">
                         <filename>unbound-anchor-1.13.2-15.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="unbound-debuginfo" release="15.oe2203sp4" version="1.13.2">
                         <filename>unbound-debuginfo-1.13.2-15.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="unbound-debugsource" release="15.oe2203sp4" version="1.13.2">
                         <filename>unbound-debugsource-1.13.2-15.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="unbound-devel" release="15.oe2203sp4" version="1.13.2">
                         <filename>unbound-devel-1.13.2-15.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="unbound-help" release="15.oe2203sp4" version="1.13.2">
                         <filename>unbound-help-1.13.2-15.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="unbound-libs" release="15.oe2203sp4" version="1.13.2">
                         <filename>unbound-libs-1.13.2-15.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-unbound" release="15.oe2203sp4" version="1.13.2">
                         <filename>python3-unbound-1.13.2-15.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="unbound" release="15.oe2203sp4" version="1.13.2">
                         <filename>unbound-1.13.2-15.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="unbound-anchor" release="15.oe2203sp4" version="1.13.2">
                         <filename>unbound-anchor-1.13.2-15.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="unbound-debuginfo" release="15.oe2203sp4" version="1.13.2">
                         <filename>unbound-debuginfo-1.13.2-15.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="unbound-debugsource" release="15.oe2203sp4" version="1.13.2">
                         <filename>unbound-debugsource-1.13.2-15.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="unbound-devel" release="15.oe2203sp4" version="1.13.2">
                         <filename>unbound-devel-1.13.2-15.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="unbound-help" release="15.oe2203sp4" version="1.13.2">
                         <filename>unbound-help-1.13.2-15.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="unbound-libs" release="15.oe2203sp4" version="1.13.2">
                         <filename>unbound-libs-1.13.2-15.oe2203sp4.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-SP4</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.oe2203sp4" version="9.0">
                         <filename>vim-X11-9.0-28.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-common" release="28.oe2203sp4" version="9.0">
                         <filename>vim-common-9.0-28.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-debuginfo" release="28.oe2203sp4" version="9.0">
                         <filename>vim-debuginfo-9.0-28.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-debugsource" release="28.oe2203sp4" version="9.0">
                         <filename>vim-debugsource-9.0-28.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-enhanced" release="28.oe2203sp4" version="9.0">
                         <filename>vim-enhanced-9.0-28.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-minimal" release="28.oe2203sp4" version="9.0">
                         <filename>vim-minimal-9.0-28.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="noarch" name="vim-filesystem" release="28.oe2203sp4" version="9.0">
                         <filename>vim-filesystem-9.0-28.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-X11" release="28.oe2203sp4" version="9.0">
                         <filename>vim-X11-9.0-28.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-common" release="28.oe2203sp4" version="9.0">
                         <filename>vim-common-9.0-28.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-debuginfo" release="28.oe2203sp4" version="9.0">
                         <filename>vim-debuginfo-9.0-28.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-debugsource" release="28.oe2203sp4" version="9.0">
                         <filename>vim-debugsource-9.0-28.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-enhanced" release="28.oe2203sp4" version="9.0">
                         <filename>vim-enhanced-9.0-28.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-minimal" release="28.oe2203sp4" version="9.0">
                         <filename>vim-minimal-9.0-28.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2238</id>
          <title>An update for xterm is now available for openEuler-22.03-LTS-SP4</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.oe2203sp4" version="363">
                         <filename>xterm-363-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xterm-debuginfo" release="6.oe2203sp4" version="363">
                         <filename>xterm-debuginfo-363-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xterm-debugsource" release="6.oe2203sp4" version="363">
                         <filename>xterm-debugsource-363-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xterm-help" release="6.oe2203sp4" version="363">
                         <filename>xterm-help-363-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xterm" release="6.oe2203sp4" version="363">
                         <filename>xterm-363-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xterm-debuginfo" release="6.oe2203sp4" version="363">
                         <filename>xterm-debuginfo-363-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xterm-debugsource" release="6.oe2203sp4" version="363">
                         <filename>xterm-debugsource-363-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xterm-help" release="6.oe2203sp4" version="363">
                         <filename>xterm-help-363-6.oe2203sp4.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-SP4</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.oe2203sp4" version="3.6.14">
                         <filename>wireshark-3.6.14-11.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-debuginfo" release="11.oe2203sp4" version="3.6.14">
                         <filename>wireshark-debuginfo-3.6.14-11.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-debugsource" release="11.oe2203sp4" version="3.6.14">
                         <filename>wireshark-debugsource-3.6.14-11.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-devel" release="11.oe2203sp4" version="3.6.14">
                         <filename>wireshark-devel-3.6.14-11.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-help" release="11.oe2203sp4" version="3.6.14">
                         <filename>wireshark-help-3.6.14-11.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark" release="11.oe2203sp4" version="3.6.14">
                         <filename>wireshark-3.6.14-11.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-debuginfo" release="11.oe2203sp4" version="3.6.14">
                         <filename>wireshark-debuginfo-3.6.14-11.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-debugsource" release="11.oe2203sp4" version="3.6.14">
                         <filename>wireshark-debugsource-3.6.14-11.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-devel" release="11.oe2203sp4" version="3.6.14">
                         <filename>wireshark-devel-3.6.14-11.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-help" release="11.oe2203sp4" version="3.6.14">
                         <filename>wireshark-help-3.6.14-11.oe2203sp4.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-SP4</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.oe2203sp4" version="2.2">
                         <filename>fop-2.2-9.oe2203sp4.noarch.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-SP4</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.oe2203sp4" version="0.21.0">
                         <filename>opensc-0.21.0-11.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="opensc-debuginfo" release="11.oe2203sp4" version="0.21.0">
                         <filename>opensc-debuginfo-0.21.0-11.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="opensc-debugsource" release="11.oe2203sp4" version="0.21.0">
                         <filename>opensc-debugsource-0.21.0-11.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="opensc-help" release="11.oe2203sp4" version="0.21.0">
                         <filename>opensc-help-0.21.0-11.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="opensc" release="11.oe2203sp4" version="0.21.0">
                         <filename>opensc-0.21.0-11.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="opensc-debuginfo" release="11.oe2203sp4" version="0.21.0">
                         <filename>opensc-debuginfo-0.21.0-11.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="opensc-debugsource" release="11.oe2203sp4" version="0.21.0">
                         <filename>opensc-debugsource-0.21.0-11.oe2203sp4.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-SP4</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.oe2203sp4" version="1.28.9">
                         <filename>cups-filters-1.28.9-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="cups-filters-debuginfo" release="5.oe2203sp4" version="1.28.9">
                         <filename>cups-filters-debuginfo-1.28.9-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="cups-filters-debugsource" release="5.oe2203sp4" version="1.28.9">
                         <filename>cups-filters-debugsource-1.28.9-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="cups-filters-devel" release="5.oe2203sp4" version="1.28.9">
                         <filename>cups-filters-devel-1.28.9-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="cups-filters-help" release="5.oe2203sp4" version="1.28.9">
                         <filename>cups-filters-help-1.28.9-5.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cups-filters" release="5.oe2203sp4" version="1.28.9">
                         <filename>cups-filters-1.28.9-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cups-filters-debuginfo" release="5.oe2203sp4" version="1.28.9">
                         <filename>cups-filters-debuginfo-1.28.9-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cups-filters-debugsource" release="5.oe2203sp4" version="1.28.9">
                         <filename>cups-filters-debugsource-1.28.9-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cups-filters-devel" release="5.oe2203sp4" version="1.28.9">
                         <filename>cups-filters-devel-1.28.9-5.oe2203sp4.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-SP4</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.oe2203sp4" version="8.0.30">
                         <filename>php-8.0.30-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-bcmath" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-bcmath-8.0.30-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-cli" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-cli-8.0.30-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-common" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-common-8.0.30-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-dba" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-dba-8.0.30-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-dbg" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-dbg-8.0.30-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-debuginfo" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-debuginfo-8.0.30-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-debugsource" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-debugsource-8.0.30-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-devel" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-devel-8.0.30-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-embedded" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-embedded-8.0.30-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-enchant" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-enchant-8.0.30-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-ffi" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-ffi-8.0.30-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-fpm" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-fpm-8.0.30-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-gd" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-gd-8.0.30-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-gmp" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-gmp-8.0.30-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-help" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-help-8.0.30-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-intl" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-intl-8.0.30-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-ldap" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-ldap-8.0.30-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-mbstring" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-mbstring-8.0.30-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-mysqlnd" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-mysqlnd-8.0.30-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-odbc" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-odbc-8.0.30-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-opcache" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-opcache-8.0.30-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-pdo" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-pdo-8.0.30-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-pgsql" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-pgsql-8.0.30-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-process" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-process-8.0.30-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-snmp" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-snmp-8.0.30-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-soap" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-soap-8.0.30-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-sodium" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-sodium-8.0.30-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-tidy" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-tidy-8.0.30-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-xml" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-xml-8.0.30-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-8.0.30-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-bcmath" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-bcmath-8.0.30-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-cli" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-cli-8.0.30-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-common" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-common-8.0.30-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-dba" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-dba-8.0.30-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-dbg" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-dbg-8.0.30-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-debuginfo" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-debuginfo-8.0.30-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-debugsource" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-debugsource-8.0.30-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-devel" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-devel-8.0.30-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-embedded" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-embedded-8.0.30-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-enchant" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-enchant-8.0.30-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-ffi" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-ffi-8.0.30-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-fpm" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-fpm-8.0.30-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-gd" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-gd-8.0.30-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-gmp" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-gmp-8.0.30-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-help" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-help-8.0.30-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-intl" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-intl-8.0.30-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-ldap" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-ldap-8.0.30-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-mbstring" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-mbstring-8.0.30-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-mysqlnd" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-mysqlnd-8.0.30-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-odbc" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-odbc-8.0.30-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-opcache" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-opcache-8.0.30-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-pdo" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-pdo-8.0.30-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-pgsql" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-pgsql-8.0.30-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-process" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-process-8.0.30-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-snmp" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-snmp-8.0.30-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-soap" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-soap-8.0.30-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-sodium" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-sodium-8.0.30-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-tidy" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-tidy-8.0.30-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-xml" release="6.oe2203sp4" version="8.0.30">
                         <filename>php-xml-8.0.30-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2252</id>
          <title>An update for rubygem-puma is now available for openEuler-22.03-LTS-SP4</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.oe2203sp4" version="5.6.5">
                         <filename>rubygem-puma-5.6.5-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-puma-debuginfo" release="3.oe2203sp4" version="5.6.5">
                         <filename>rubygem-puma-debuginfo-5.6.5-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-puma-debugsource" release="3.oe2203sp4" version="5.6.5">
                         <filename>rubygem-puma-debugsource-5.6.5-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-puma-doc" release="3.oe2203sp4" version="5.6.5">
                         <filename>rubygem-puma-doc-5.6.5-3.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-puma" release="3.oe2203sp4" version="5.6.5">
                         <filename>rubygem-puma-5.6.5-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-puma-debuginfo" release="3.oe2203sp4" version="5.6.5">
                         <filename>rubygem-puma-debuginfo-5.6.5-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-puma-debugsource" release="3.oe2203sp4" version="5.6.5">
                         <filename>rubygem-puma-debugsource-5.6.5-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2253</id>
          <title>An update for runc is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2024-10-12"></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="25.oe2203sp4" version="1.1.3">
                         <filename>docker-runc-1.1.3-25.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="runc" release="30.oe2203sp4" version="1.1.3">
                         <filename>runc-1.1.3-30.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="docker-runc" release="25.oe2203sp4" version="1.1.3">
                         <filename>docker-runc-1.1.3-25.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="runc" release="30.oe2203sp4" version="1.1.3">
                         <filename>runc-1.1.3-30.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2258</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2024-10-18"></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-2022-48893" id="CVE-2022-48893" title="CVE-2022-48893" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35825" id="CVE-2024-35825" title="CVE-2024-35825" 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-36005" id="CVE-2024-36005" title="CVE-2024-36005" 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-36270" id="CVE-2024-36270" title="CVE-2024-36270" 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-36915" id="CVE-2024-36915" title="CVE-2024-36915" 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-36946" id="CVE-2024-36946" title="CVE-2024-36946" 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-38560" id="CVE-2024-38560" title="CVE-2024-38560" 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-38613" id="CVE-2024-38613" title="CVE-2024-38613" 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-39292" id="CVE-2024-39292" title="CVE-2024-39292" 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-40932" id="CVE-2024-40932" title="CVE-2024-40932" 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-41019" id="CVE-2024-41019" title="CVE-2024-41019" 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-41048" id="CVE-2024-41048" title="CVE-2024-41048" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41049" id="CVE-2024-41049" title="CVE-2024-41049" 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-41069" id="CVE-2024-41069" title="CVE-2024-41069" 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-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-42067" id="CVE-2024-42067" title="CVE-2024-42067" 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-42097" id="CVE-2024-42097" title="CVE-2024-42097" 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-42129" id="CVE-2024-42129" title="CVE-2024-42129" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42228" id="CVE-2024-42228" title="CVE-2024-42228" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-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-42306" id="CVE-2024-42306" title="CVE-2024-42306" 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-43840" id="CVE-2024-43840" title="CVE-2024-43840" 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-43872" id="CVE-2024-43872" title="CVE-2024-43872" 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-44954" id="CVE-2024-44954" title="CVE-2024-44954" 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-46826" id="CVE-2024-46826" title="CVE-2024-46826" 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: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: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:usb: gadget: ncm: Fix handling of zero block length packetsWhile connecting to a Linux host with CDC_NCM_NTB_DEF_SIZE_TXset to 65536, it has been observed that we receive short packets,which come at interval of 5-10 seconds sometimes and have blocklength zero but still contain 1-2 valid datagrams present.According to the NCM spec:&#34;If wBlockLength = 0x0000, the block is terminated by ashort packet. In this case, the USB transfer must stillbe shorter than dwNtbInMaxSize or dwNtbOutMaxSize. Ifexactly dwNtbInMaxSize or dwNtbOutMaxSize bytes are sent,and the size is a multiple of wMaxPacketSize for thegiven pipe, then no ZLP shall be sent.wBlockLength= 0x0000 must be used with extreme care, becauseof the possibility that the host and device may get out ofsync, and because of test issues.wBlockLength = 0x0000 allows the sender to reduce latency bystarting to send a very large NTB, and then shortening it whenthe sender discovers that there’s not sufficient data to justifysending a large NTB&#34;However, there is a potential issue with the current implementation,as it checks for the occurrence of multiple NTBs in a singlegiveback by verifying if the leftover bytes to be processed is zeroor not. If the block length reads zero, we would process the sameNTB infintely because the leftover bytes is never zero and it leadsto a crash. Fix this by bailing out if block length reads zero.(CVE-2024-35825)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:netfilter: nf_tables: honor table dormant flag from netdev release event pathCheck for table dormant flag otherwise netdev release event path triesto unregister an already unregistered hook.[524854.857999] ------------[ cut here ]------------[524854.858010] WARNING: CPU: 0 PID: 3386599 at net/netfilter/core.c:501 __nf_unregister_net_hook+0x21a/0x260[...][524854.858848] CPU: 0 PID: 3386599 Comm: kworker/u32:2 Not tainted 6.9.0-rc3+ #365[524854.858869] Workqueue: netns cleanup_net[524854.858886] RIP: 0010:__nf_unregister_net_hook+0x21a/0x260[524854.858903] Code: 24 e8 aa 73 83 ff 48 63 43 1c 83 f8 01 0f 85 3d ff ff ff e8 98 d1 f0 ff 48 8b 3c 24 e8 8f 73 83 ff 48 63 43 1c e9 26 ff ff ff &lt;0f&gt; 0b 48 83 c4 18 48 c7 c7 00 68 e9 82 5b 5d 41 5c 41 5d 41 5e 41[524854.858914] RSP: 0018:ffff8881e36d79e0 EFLAGS: 00010246[524854.858926] RAX: 0000000000000000 RBX: ffff8881339ae790 RCX: ffffffff81ba524a[524854.858936] RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff8881c8a16438[524854.858945] RBP: ffff8881c8a16438 R08: 0000000000000001 R09: ffffed103c6daf34[524854.858954] R10: ffff8881e36d79a7 R11: 0000000000000000 R12: 0000000000000005[524854.858962] R13: ffff8881c8a16000 R14: 0000000000000000 R15: ffff8881351b5a00[524854.858971] FS:  0000000000000000(0000) GS:ffff888390800000(0000) knlGS:0000000000000000[524854.858982] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033[524854.858991] CR2: 00007fc9be0f16f4 CR3: 00000001437cc004 CR4: 00000000001706f0[524854.859000] Call Trace:[524854.859006]  &lt;TASK&gt;[524854.859013]  ? __warn+0x9f/0x1a0[524854.859027]  ? __nf_unregister_net_hook+0x21a/0x260[524854.859044]  ? report_bug+0x1b1/0x1e0[524854.859060]  ? handle_bug+0x3c/0x70[524854.859071]  ? exc_invalid_op+0x17/0x40[524854.859083]  ? asm_exc_invalid_op+0x1a/0x20[524854.859100]  ? __nf_unregister_net_hook+0x6a/0x260[524854.859116]  ? __nf_unregister_net_hook+0x21a/0x260[524854.859135]  nf_tables_netdev_event+0x337/0x390 [nf_tables][524854.859304]  ? __pfx_nf_tables_netdev_event+0x10/0x10 [nf_tables][524854.859461]  ? packet_notifier+0xb3/0x360[524854.859476]  ? _raw_spin_unlock_irqrestore+0x11/0x40[524854.859489]  ? dcbnl_netdevice_event+0x35/0x140[524854.859507]  ? __pfx_nf_tables_netdev_event+0x10/0x10 [nf_tables][524854.859661]  notifier_call_chain+0x7d/0x140[524854.859677]  unregister_netdevice_many_notify+0x5e1/0xae0(CVE-2024-36005)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: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: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: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: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: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: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: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: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: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: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: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)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: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: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: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: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: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:filelock: fix potential use-after-free in posix_lock_inodeLight Hsieh reported a KASAN UAF warning in trace_posix_lock_inode().The request pointer had been changed earlier to point to a lock entrythat was added to the inode&#39;s list. However, before the tracepoint couldfire, another task raced in and freed that lock.Fix this by moving the tracepoint inside the spinlock, which shouldensure that this doesn&#39;t happen.(CVE-2024-41049)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: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: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: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: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: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: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: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: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: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)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:udf: Avoid using corrupted block bitmap bufferWhen the filesystem block bitmap is corrupted, we detect the corruptionwhile loading the bitmap and fail the allocation with error. However thenext allocation from the same bitmap will notice the bitmap buffer isalready loaded and tries to allocate from the bitmap with mixed results(depending on the exact nature of the bitmap corruption). Fix theproblem by using BH_verified bit to indicate whether the bitmap is validor not.(CVE-2024-42306)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:bpf, arm64: Fix trampoline for BPF_TRAMP_F_CALL_ORIGWhen BPF_TRAMP_F_CALL_ORIG is set, the trampoline calls__bpf_tramp_enter() and __bpf_tramp_exit() functions, passing themthe struct bpf_tramp_image *im pointer as an argument in R0.The trampoline generation code uses emit_addr_mov_i64() to emitinstructions for moving the bpf_tramp_image address into R0, butemit_addr_mov_i64() assumes the address to be in the vmalloc() spaceand uses only 48 bits. Because bpf_tramp_image is allocated usingkzalloc(), its address can use more than 48-bits, in this case thetrampoline will pass an invalid address to __bpf_tramp_enter/exit()causing a kernel crash.Fix this by using emit_a64_mov_i64() in place of emit_addr_mov_i64()as it can work with addresses that are greater than 48-bits.(CVE-2024-43840)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:RDMA/hns: Fix soft lockup under heavy CEQE loadCEQEs are handled in interrupt handler currently. This may cause theCPU core staying in interrupt context too long and lead to soft lockupunder heavy load.Handle CEQEs in BH workqueue and set an upper limit for the number ofCEQE handled by a single call of work handler.(CVE-2024-43872)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: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: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:ELF: fix kernel.randomize_va_space double readELF loader uses &#34;randomize_va_space&#34; twice. It is sysctl and can changeat any moment, so 2 loads could see 2 different values in theory withunpredictable consequences.Issue exactly one load for consistent value across one exec.(CVE-2024-46826)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="bpftool" release="232.0.0.131.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-232.0.0.131.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="232.0.0.131.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-232.0.0.131.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="232.0.0.131.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-232.0.0.131.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="232.0.0.131.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-232.0.0.131.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="232.0.0.131.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-232.0.0.131.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="232.0.0.131.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-232.0.0.131.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="232.0.0.131.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-232.0.0.131.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="232.0.0.131.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-232.0.0.131.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="232.0.0.131.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-232.0.0.131.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="232.0.0.131.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-232.0.0.131.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="232.0.0.131.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-232.0.0.131.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="232.0.0.131.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-232.0.0.131.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="232.0.0.131.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-232.0.0.131.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="232.0.0.131.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-232.0.0.131.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="232.0.0.131.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-232.0.0.131.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="232.0.0.131.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-232.0.0.131.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="232.0.0.131.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-232.0.0.131.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="232.0.0.131.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-232.0.0.131.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="232.0.0.131.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-232.0.0.131.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="232.0.0.131.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-232.0.0.131.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="232.0.0.131.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-232.0.0.131.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="232.0.0.131.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-232.0.0.131.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="232.0.0.131.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-232.0.0.131.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="232.0.0.131.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-232.0.0.131.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="232.0.0.131.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-232.0.0.131.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="232.0.0.131.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-232.0.0.131.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="232.0.0.131.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-232.0.0.131.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="232.0.0.131.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-232.0.0.131.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="232.0.0.131.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-232.0.0.131.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="232.0.0.131.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-232.0.0.131.oe2203sp4.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-SP4</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.oe2203sp4" version="7.5.15">
                         <filename>grafana-7.5.15-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="grafana-debuginfo" release="7.oe2203sp4" version="7.5.15">
                         <filename>grafana-debuginfo-7.5.15-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="grafana" release="7.oe2203sp4" version="7.5.15">
                         <filename>grafana-7.5.15-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="grafana-debuginfo" release="7.oe2203sp4" version="7.5.15">
                         <filename>grafana-debuginfo-7.5.15-7.oe2203sp4.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-SP4</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.oe2203sp4" version="202011">
                         <filename>edk2-debuginfo-202011-21.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="edk2-debugsource" release="21.oe2203sp4" version="202011">
                         <filename>edk2-debugsource-202011-21.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="edk2-devel" release="21.oe2203sp4" version="202011">
                         <filename>edk2-devel-202011-21.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-aarch64" release="21.oe2203sp4" version="202011">
                         <filename>edk2-aarch64-202011-21.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-help" release="21.oe2203sp4" version="202011">
                         <filename>edk2-help-202011-21.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-ovmf" release="21.oe2203sp4" version="202011">
                         <filename>edk2-ovmf-202011-21.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-edk2-devel" release="21.oe2203sp4" version="202011">
                         <filename>python3-edk2-devel-202011-21.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-debuginfo" release="21.oe2203sp4" version="202011">
                         <filename>edk2-debuginfo-202011-21.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-debugsource" release="21.oe2203sp4" version="202011">
                         <filename>edk2-debugsource-202011-21.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-devel" release="21.oe2203sp4" version="202011">
                         <filename>edk2-devel-202011-21.oe2203sp4.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-SP4</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="16.oe2203sp4" version="1.13.2">
                         <filename>python3-unbound-1.13.2-16.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="unbound" release="16.oe2203sp4" version="1.13.2">
                         <filename>unbound-1.13.2-16.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="unbound-anchor" release="16.oe2203sp4" version="1.13.2">
                         <filename>unbound-anchor-1.13.2-16.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="unbound-debuginfo" release="16.oe2203sp4" version="1.13.2">
                         <filename>unbound-debuginfo-1.13.2-16.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="unbound-debugsource" release="16.oe2203sp4" version="1.13.2">
                         <filename>unbound-debugsource-1.13.2-16.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="unbound-devel" release="16.oe2203sp4" version="1.13.2">
                         <filename>unbound-devel-1.13.2-16.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="unbound-help" release="16.oe2203sp4" version="1.13.2">
                         <filename>unbound-help-1.13.2-16.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="unbound-libs" release="16.oe2203sp4" version="1.13.2">
                         <filename>unbound-libs-1.13.2-16.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-unbound" release="16.oe2203sp4" version="1.13.2">
                         <filename>python3-unbound-1.13.2-16.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="unbound" release="16.oe2203sp4" version="1.13.2">
                         <filename>unbound-1.13.2-16.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="unbound-anchor" release="16.oe2203sp4" version="1.13.2">
                         <filename>unbound-anchor-1.13.2-16.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="unbound-debuginfo" release="16.oe2203sp4" version="1.13.2">
                         <filename>unbound-debuginfo-1.13.2-16.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="unbound-debugsource" release="16.oe2203sp4" version="1.13.2">
                         <filename>unbound-debugsource-1.13.2-16.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="unbound-devel" release="16.oe2203sp4" version="1.13.2">
                         <filename>unbound-devel-1.13.2-16.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="unbound-help" release="16.oe2203sp4" version="1.13.2">
                         <filename>unbound-help-1.13.2-16.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="unbound-libs" release="16.oe2203sp4" version="1.13.2">
                         <filename>unbound-libs-1.13.2-16.oe2203sp4.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-SP4</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 epoch="10" arch="aarch64" name="qemu" release="100.oe2203sp4" version="6.2.0">
                         <filename>qemu-6.2.0-100.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-curl" release="100.oe2203sp4" version="6.2.0">
                         <filename>qemu-block-curl-6.2.0-100.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-iscsi" release="100.oe2203sp4" version="6.2.0">
                         <filename>qemu-block-iscsi-6.2.0-100.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-rbd" release="100.oe2203sp4" version="6.2.0">
                         <filename>qemu-block-rbd-6.2.0-100.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-ssh" release="100.oe2203sp4" version="6.2.0">
                         <filename>qemu-block-ssh-6.2.0-100.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-debuginfo" release="100.oe2203sp4" version="6.2.0">
                         <filename>qemu-debuginfo-6.2.0-100.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-debugsource" release="100.oe2203sp4" version="6.2.0">
                         <filename>qemu-debugsource-6.2.0-100.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-guest-agent" release="100.oe2203sp4" version="6.2.0">
                         <filename>qemu-guest-agent-6.2.0-100.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-hw-usb-host" release="100.oe2203sp4" version="6.2.0">
                         <filename>qemu-hw-usb-host-6.2.0-100.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-img" release="100.oe2203sp4" version="6.2.0">
                         <filename>qemu-img-6.2.0-100.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-aarch64" release="100.oe2203sp4" version="6.2.0">
                         <filename>qemu-system-aarch64-6.2.0-100.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-arm" release="100.oe2203sp4" version="6.2.0">
                         <filename>qemu-system-arm-6.2.0-100.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-riscv" release="100.oe2203sp4" version="6.2.0">
                         <filename>qemu-system-riscv-6.2.0-100.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-x86_64" release="100.oe2203sp4" version="6.2.0">
                         <filename>qemu-system-x86_64-6.2.0-100.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="noarch" name="qemu-help" release="100.oe2203sp4" version="6.2.0">
                         <filename>qemu-help-6.2.0-100.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu" release="100.oe2203sp4" version="6.2.0">
                         <filename>qemu-6.2.0-100.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-curl" release="100.oe2203sp4" version="6.2.0">
                         <filename>qemu-block-curl-6.2.0-100.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-iscsi" release="100.oe2203sp4" version="6.2.0">
                         <filename>qemu-block-iscsi-6.2.0-100.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-rbd" release="100.oe2203sp4" version="6.2.0">
                         <filename>qemu-block-rbd-6.2.0-100.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-ssh" release="100.oe2203sp4" version="6.2.0">
                         <filename>qemu-block-ssh-6.2.0-100.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-debuginfo" release="100.oe2203sp4" version="6.2.0">
                         <filename>qemu-debuginfo-6.2.0-100.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-debugsource" release="100.oe2203sp4" version="6.2.0">
                         <filename>qemu-debugsource-6.2.0-100.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-guest-agent" release="100.oe2203sp4" version="6.2.0">
                         <filename>qemu-guest-agent-6.2.0-100.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-hw-usb-host" release="100.oe2203sp4" version="6.2.0">
                         <filename>qemu-hw-usb-host-6.2.0-100.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-img" release="100.oe2203sp4" version="6.2.0">
                         <filename>qemu-img-6.2.0-100.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-seabios" release="100.oe2203sp4" version="6.2.0">
                         <filename>qemu-seabios-6.2.0-100.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-aarch64" release="100.oe2203sp4" version="6.2.0">
                         <filename>qemu-system-aarch64-6.2.0-100.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-arm" release="100.oe2203sp4" version="6.2.0">
                         <filename>qemu-system-arm-6.2.0-100.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-riscv" release="100.oe2203sp4" version="6.2.0">
                         <filename>qemu-system-riscv-6.2.0-100.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-x86_64" release="100.oe2203sp4" version="6.2.0">
                         <filename>qemu-system-x86_64-6.2.0-100.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2271</id>
          <title>An update for redis is now available for openEuler-22.03-LTS-SP4</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.oe2203sp4" version="4.0.14">
                         <filename>redis-4.0.14-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="redis-debuginfo" release="7.oe2203sp4" version="4.0.14">
                         <filename>redis-debuginfo-4.0.14-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="redis-debugsource" release="7.oe2203sp4" version="4.0.14">
                         <filename>redis-debugsource-4.0.14-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="redis" release="7.oe2203sp4" version="4.0.14">
                         <filename>redis-4.0.14-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="redis-debuginfo" release="7.oe2203sp4" version="4.0.14">
                         <filename>redis-debuginfo-4.0.14-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="redis-debugsource" release="7.oe2203sp4" version="4.0.14">
                         <filename>redis-debugsource-4.0.14-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2278</id>
          <title>An update for python-django is now available for openEuler-22.03-LTS-SP4</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.oe2203sp4" version="4.2.15">
                         <filename>python-django-help-4.2.15-2.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-Django" release="2.oe2203sp4" version="4.2.15">
                         <filename>python3-Django-4.2.15-2.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2287</id>
          <title>An update for mysql is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-10-25"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21185" id="CVE-2024-21185" title="CVE-2024-21185" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21193" id="CVE-2024-21193" title="CVE-2024-21193" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21194" id="CVE-2024-21194" title="CVE-2024-21194" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21196" id="CVE-2024-21196" title="CVE-2024-21196" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21197" id="CVE-2024-21197" title="CVE-2024-21197" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21198" id="CVE-2024-21198" title="CVE-2024-21198" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21199" id="CVE-2024-21199" title="CVE-2024-21199" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21201" id="CVE-2024-21201" title="CVE-2024-21201" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21203" id="CVE-2024-21203" title="CVE-2024-21203" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21207" id="CVE-2024-21207" title="CVE-2024-21207" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21212" id="CVE-2024-21212" title="CVE-2024-21212" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21213" id="CVE-2024-21213" title="CVE-2024-21213" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21218" id="CVE-2024-21218" title="CVE-2024-21218" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21219" id="CVE-2024-21219" title="CVE-2024-21219" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21230" id="CVE-2024-21230" title="CVE-2024-21230" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21231" id="CVE-2024-21231" title="CVE-2024-21231" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21236" id="CVE-2024-21236" title="CVE-2024-21236" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21237" id="CVE-2024-21237" title="CVE-2024-21237" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21238" id="CVE-2024-21238" title="CVE-2024-21238" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21239" id="CVE-2024-21239" title="CVE-2024-21239" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21241" id="CVE-2024-21241" title="CVE-2024-21241" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21247" id="CVE-2024-21247" title="CVE-2024-21247" type="cve"></reference>
          </references>
          <description>Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.38, 8.4.1 and  9.0.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).(CVE-2024-21185)Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: PS).  Supported versions that are affected are 8.0.39 and prior, 8.4.2 and prior and  9.0.1 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).(CVE-2024-21193)Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.39 and prior, 8.4.2 and prior and  9.0.1 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).(CVE-2024-21194)Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: X Plugin).  Supported versions that are affected are 8.0.39 and prior, 8.4.2 and prior and  9.0.1 and prior. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).(CVE-2024-21196)Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Information Schema).  Supported versions that are affected are 8.0.39 and prior, 8.4.2 and prior and  9.0.1 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).(CVE-2024-21197)Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: DDL).  Supported versions that are affected are 8.0.39 and prior, 8.4.2 and prior and  9.0.1 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).(CVE-2024-21198)Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.39 and prior, 8.4.2 and prior and  9.0.1 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).(CVE-2024-21199)Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.39 and prior, 8.4.2 and prior and  9.0.1 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).(CVE-2024-21201)Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: FTS).  Supported versions that are affected are 8.0.39 and prior, 8.4.2 and prior and  9.0.1 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).(CVE-2024-21203)Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.38 and prior, 8.4.1 and prior and  9.0.1 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).(CVE-2024-21207)Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Health Monitor).  Supported versions that are affected are 8.0.39 and prior and  8.4.0. Difficult to exploit vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.4 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H).(CVE-2024-21212)Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.39 and prior, 8.4.2 and prior and  9.0.1 and prior. Easily exploitable vulnerability allows high privileged attacker with logon to the infrastructure where MySQL Server executes to compromise MySQL Server.  Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.2 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:H/UI:R/S:U/C:N/I:N/A:H).(CVE-2024-21213)Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.39 and prior, 8.4.2 and prior and  9.0.1 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (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-21218)Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: DML).  Supported versions that are affected are 8.0.39 and prior, 8.4.2 and prior and  9.0.1 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).(CVE-2024-21219)Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.39 and prior, 8.4.2 and prior and  9.0.1 and prior. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).(CVE-2024-21230)Vulnerability in the MySQL Server product of Oracle MySQL (component: Client programs).  Supported versions that are affected are 8.0.39 and prior, 8.4.2 and prior and  9.0.1 and prior. Difficult to exploit vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of MySQL Server. CVSS 3.1 Base Score 3.1 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L).(CVE-2024-21231)Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.39 and prior, 8.4.2 and prior and  9.0.1 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).(CVE-2024-21236)Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Group Replication GCS).  Supported versions that are affected are 8.0.39 and prior, 8.4.2 and prior and  9.0.1 and prior. Difficult to exploit vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of MySQL Server. CVSS 3.1 Base Score 2.2 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:L).(CVE-2024-21237)Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Thread Pooling).  Supported versions that are affected are 8.0.39 and prior, 8.4.1 and prior and  9.0.1 and prior. Difficult to exploit vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 5.3 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H).(CVE-2024-21238)Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.39 and prior, 8.4.2 and prior and  9.0.1 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).(CVE-2024-21239)Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.39 and prior, 8.4.2 and prior and  9.0.1 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).(CVE-2024-21241)Vulnerability in the MySQL Client product of Oracle MySQL (component: Client: mysqldump).  Supported versions that are affected are 8.0.39 and prior, 8.4.2 and prior and  9.0.1 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Client.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of MySQL Client accessible data as well as  unauthorized read access to a subset of MySQL Client accessible data. CVSS 3.1 Base Score 3.8 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:N).(CVE-2024-21247)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="mysql" release="1.oe2203sp4" version="8.0.40">
                         <filename>mysql-8.0.40-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-common" release="1.oe2203sp4" version="8.0.40">
                         <filename>mysql-common-8.0.40-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-config" release="1.oe2203sp4" version="8.0.40">
                         <filename>mysql-config-8.0.40-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-debuginfo" release="1.oe2203sp4" version="8.0.40">
                         <filename>mysql-debuginfo-8.0.40-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-debugsource" release="1.oe2203sp4" version="8.0.40">
                         <filename>mysql-debugsource-8.0.40-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-devel" release="1.oe2203sp4" version="8.0.40">
                         <filename>mysql-devel-8.0.40-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-errmsg" release="1.oe2203sp4" version="8.0.40">
                         <filename>mysql-errmsg-8.0.40-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-help" release="1.oe2203sp4" version="8.0.40">
                         <filename>mysql-help-8.0.40-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-libs" release="1.oe2203sp4" version="8.0.40">
                         <filename>mysql-libs-8.0.40-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-server" release="1.oe2203sp4" version="8.0.40">
                         <filename>mysql-server-8.0.40-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-test" release="1.oe2203sp4" version="8.0.40">
                         <filename>mysql-test-8.0.40-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql" release="1.oe2203sp4" version="8.0.40">
                         <filename>mysql-8.0.40-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-common" release="1.oe2203sp4" version="8.0.40">
                         <filename>mysql-common-8.0.40-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-config" release="1.oe2203sp4" version="8.0.40">
                         <filename>mysql-config-8.0.40-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-debuginfo" release="1.oe2203sp4" version="8.0.40">
                         <filename>mysql-debuginfo-8.0.40-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-debugsource" release="1.oe2203sp4" version="8.0.40">
                         <filename>mysql-debugsource-8.0.40-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-devel" release="1.oe2203sp4" version="8.0.40">
                         <filename>mysql-devel-8.0.40-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-errmsg" release="1.oe2203sp4" version="8.0.40">
                         <filename>mysql-errmsg-8.0.40-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-help" release="1.oe2203sp4" version="8.0.40">
                         <filename>mysql-help-8.0.40-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-libs" release="1.oe2203sp4" version="8.0.40">
                         <filename>mysql-libs-8.0.40-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-server" release="1.oe2203sp4" version="8.0.40">
                         <filename>mysql-server-8.0.40-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-test" release="1.oe2203sp4" version="8.0.40">
                         <filename>mysql-test-8.0.40-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2288</id>
          <title>An update for httpd is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-10-25"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40725" id="CVE-2024-40725" title="CVE-2024-40725" type="cve"></reference>
          </references>
          <description>A partial fix for  CVE-2024-39884 in the core of Apache HTTP Server 2.4.61 ignores some use of the legacy content-type based configuration of handlers. &#34;AddType&#34; and similar configuration, under some circumstances where files are requested indirectly, result in source code disclosure of local content. For example, PHP scripts may be served instead of interpreted.Users are recommended to upgrade to version 2.4.62, which fixes this issue.(CVE-2024-40725)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="httpd" release="23.oe2203sp4" version="2.4.51">
                         <filename>httpd-2.4.51-23.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd-debuginfo" release="23.oe2203sp4" version="2.4.51">
                         <filename>httpd-debuginfo-2.4.51-23.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd-debugsource" release="23.oe2203sp4" version="2.4.51">
                         <filename>httpd-debugsource-2.4.51-23.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd-devel" release="23.oe2203sp4" version="2.4.51">
                         <filename>httpd-devel-2.4.51-23.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd-tools" release="23.oe2203sp4" version="2.4.51">
                         <filename>httpd-tools-2.4.51-23.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_ldap" release="23.oe2203sp4" version="2.4.51">
                         <filename>mod_ldap-2.4.51-23.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_md" release="23.oe2203sp4" version="2.4.51">
                         <filename>mod_md-2.4.51-23.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mod_proxy_html" release="23.oe2203sp4" version="2.4.51">
                         <filename>mod_proxy_html-2.4.51-23.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_session" release="23.oe2203sp4" version="2.4.51">
                         <filename>mod_session-2.4.51-23.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mod_ssl" release="23.oe2203sp4" version="2.4.51">
                         <filename>mod_ssl-2.4.51-23.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="httpd-filesystem" release="23.oe2203sp4" version="2.4.51">
                         <filename>httpd-filesystem-2.4.51-23.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="httpd-help" release="23.oe2203sp4" version="2.4.51">
                         <filename>httpd-help-2.4.51-23.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd" release="23.oe2203sp4" version="2.4.51">
                         <filename>httpd-2.4.51-23.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-debuginfo" release="23.oe2203sp4" version="2.4.51">
                         <filename>httpd-debuginfo-2.4.51-23.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-debugsource" release="23.oe2203sp4" version="2.4.51">
                         <filename>httpd-debugsource-2.4.51-23.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-devel" release="23.oe2203sp4" version="2.4.51">
                         <filename>httpd-devel-2.4.51-23.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-tools" release="23.oe2203sp4" version="2.4.51">
                         <filename>httpd-tools-2.4.51-23.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_ldap" release="23.oe2203sp4" version="2.4.51">
                         <filename>mod_ldap-2.4.51-23.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_md" release="23.oe2203sp4" version="2.4.51">
                         <filename>mod_md-2.4.51-23.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mod_proxy_html" release="23.oe2203sp4" version="2.4.51">
                         <filename>mod_proxy_html-2.4.51-23.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_session" release="23.oe2203sp4" version="2.4.51">
                         <filename>mod_session-2.4.51-23.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mod_ssl" release="23.oe2203sp4" version="2.4.51">
                         <filename>mod_ssl-2.4.51-23.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2290</id>
          <title>An update for OpenIPMI is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-10-25"></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.oe2203sp4" version="2.0.32">
                         <filename>OpenIPMI-2.0.32-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="OpenIPMI-debuginfo" release="4.oe2203sp4" version="2.0.32">
                         <filename>OpenIPMI-debuginfo-2.0.32-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="OpenIPMI-debugsource" release="4.oe2203sp4" version="2.0.32">
                         <filename>OpenIPMI-debugsource-2.0.32-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="OpenIPMI-devel" release="4.oe2203sp4" version="2.0.32">
                         <filename>OpenIPMI-devel-2.0.32-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="OpenIPMI-perl" release="4.oe2203sp4" version="2.0.32">
                         <filename>OpenIPMI-perl-2.0.32-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-openipmi" release="4.oe2203sp4" version="2.0.32">
                         <filename>python3-openipmi-2.0.32-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="OpenIPMI-help" release="4.oe2203sp4" version="2.0.32">
                         <filename>OpenIPMI-help-2.0.32-4.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="OpenIPMI" release="4.oe2203sp4" version="2.0.32">
                         <filename>OpenIPMI-2.0.32-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="OpenIPMI-debuginfo" release="4.oe2203sp4" version="2.0.32">
                         <filename>OpenIPMI-debuginfo-2.0.32-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="OpenIPMI-debugsource" release="4.oe2203sp4" version="2.0.32">
                         <filename>OpenIPMI-debugsource-2.0.32-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="OpenIPMI-devel" release="4.oe2203sp4" version="2.0.32">
                         <filename>OpenIPMI-devel-2.0.32-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="OpenIPMI-perl" release="4.oe2203sp4" version="2.0.32">
                         <filename>OpenIPMI-perl-2.0.32-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-openipmi" release="4.oe2203sp4" version="2.0.32">
                         <filename>python3-openipmi-2.0.32-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2292</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2024-10-25"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27030" id="CVE-2024-27030" title="CVE-2024-27030" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27074" id="CVE-2024-27074" title="CVE-2024-27074" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27397" id="CVE-2024-27397" title="CVE-2024-27397" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35785" id="CVE-2024-35785" title="CVE-2024-35785" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35829" id="CVE-2024-35829" title="CVE-2024-35829" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36244" id="CVE-2024-36244" title="CVE-2024-36244" 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-36927" id="CVE-2024-36927" title="CVE-2024-36927" 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-38608" id="CVE-2024-38608" title="CVE-2024-38608" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38612" id="CVE-2024-38612" title="CVE-2024-38612" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39495" id="CVE-2024-39495" title="CVE-2024-39495" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40958" id="CVE-2024-40958" title="CVE-2024-40958" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42289" id="CVE-2024-42289" title="CVE-2024-42289" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42321" id="CVE-2024-42321" title="CVE-2024-42321" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43880" id="CVE-2024-43880" title="CVE-2024-43880" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44931" id="CVE-2024-44931" title="CVE-2024-44931" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44952" id="CVE-2024-44952" title="CVE-2024-44952" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44989" id="CVE-2024-44989" title="CVE-2024-44989" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44990" id="CVE-2024-44990" title="CVE-2024-44990" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46716" id="CVE-2024-46716" title="CVE-2024-46716" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46817" id="CVE-2024-46817" title="CVE-2024-46817" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46822" id="CVE-2024-46822" title="CVE-2024-46822" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46859" id="CVE-2024-46859" title="CVE-2024-46859" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47661" id="CVE-2024-47661" title="CVE-2024-47661" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:octeontx2-af: Use separate handlers for interruptsFor PF to AF interrupt vector and VF to AF vector sameinterrupt handler is registered which is causing race condition.When two interrupts are raised to two CPUs at same timethen two cores serve same event corrupting the data.(CVE-2024-27030)In the Linux kernel, the following vulnerability has been resolved:media: go7007: fix a memleak in go7007_load_encoderIn go7007_load_encoder, bounce(i.e. go-&gt;boot_fw), is allocated withouta deallocation thereafter. After the following call chain:saa7134_go7007_init  |-&gt; go7007_boot_encoder        |-&gt; go7007_load_encoder  |-&gt; kfree(go)go is freed and thus bounce is leaked.(CVE-2024-27074)In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: use timestamp to check for set element timeoutAdd a timestamp field at the beginning of the transaction, store itin the nftables per-netns area.Update set backend .insert, .deactivate and sync gc path to use thetimestamp, this avoids that an element expires while control planetransaction is still unfinished..lookup and .update, which are used from packet path, still use thecurrent time to check if the element has expired. And .get path and dumpalso since this runs lockless under rcu read size lock. Then, there isasync gc which also needs to check the current time since it runsasynchronously from a workqueue.(CVE-2024-27397)In the Linux kernel, the following vulnerability has been resolved:tee: optee: Fix kernel panic caused by incorrect error handlingThe error path while failing to register devices on the TEE bus has abug leading to kernel panic as follows:[   15.398930] Unable to handle kernel paging request at virtual address ffff07ed00626d7c[   15.406913] Mem abort info:[   15.409722]   ESR = 0x0000000096000005[   15.413490]   EC = 0x25: DABT (current EL), IL = 32 bits[   15.418814]   SET = 0, FnV = 0[   15.421878]   EA = 0, S1PTW = 0[   15.425031]   FSC = 0x05: level 1 translation fault[   15.429922] Data abort info:[   15.432813]   ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000[   15.438310]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0[   15.443372]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0[   15.448697] swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000d9e3e000[   15.455413] [ffff07ed00626d7c] pgd=1800000bffdf9003, p4d=1800000bffdf9003, pud=0000000000000000[   15.464146] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMPCommit 7269cba53d90 (&#34;tee: optee: Fix supplicant based device enumeration&#34;)lead to the introduction of this bug. So fix it appropriately.(CVE-2024-35785)In the Linux kernel, the following vulnerability has been resolved:drm/lima: fix a memleak in lima_heap_allocWhen lima_vm_map_bo fails, the resources need to be deallocated, orthere will be memleaks.(CVE-2024-35829)In the Linux kernel, the following vulnerability has been resolved:net/sched: taprio: extend minimum interval restriction to entire cycle tooIt is possible for syzbot to side-step the restriction imposed by theblamed commit in the Fixes: tag, because the taprio UAPI permits acycle-time different from (and potentially shorter than) the sum ofentry intervals.We need one more restriction, which is that the cycle time itself mustbe larger than N * ETH_ZLEN bit times, where N is the number of scheduleentries. This restriction needs to apply regardless of whether the cycletime came from the user or was the implicit, auto-calculated value, sowe move the existing &#34;cycle == 0&#34; check outside the &#34;if &#34;(!new-&gt;cycle_time)&#34;branch. This way covers both conditions and scenarios.Add a selftest which illustrates the issue triggered by syzbot.(CVE-2024-36244)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:ipv4: Fix uninit-value access in __ip_make_skb()KMSAN reported uninit-value access in __ip_make_skb() [1].  __ip_make_skb()tests HDRINCL to know if the skb has icmphdr. However, HDRINCL can cause arace condition. If calling setsockopt(2) with IP_HDRINCL changes HDRINCLwhile __ip_make_skb() is running, the function will access icmphdr in theskb even if it is not included. This causes the issue reported by KMSAN.Check FLOWI_FLAG_KNOWN_NH on fl4-&gt;flowi4_flags instead of testing HDRINCLon the socket.Also, fl4-&gt;fl4_icmp_type and fl4-&gt;fl4_icmp_code are not initialized. Theseare union in struct flowi4 and are implicitly initialized byflowi4_init_output(), but we should not rely on specific union layout.Initialize these explicitly in raw_sendmsg().[1]BUG: KMSAN: uninit-value in __ip_make_skb+0x2b74/0x2d20 net/ipv4/ip_output.c:1481 __ip_make_skb+0x2b74/0x2d20 net/ipv4/ip_output.c:1481 ip_finish_skb include/net/ip.h:243 [inline] ip_push_pending_frames+0x4c/0x5c0 net/ipv4/ip_output.c:1508 raw_sendmsg+0x2381/0x2690 net/ipv4/raw.c:654 inet_sendmsg+0x27b/0x2a0 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x274/0x3c0 net/socket.c:745 __sys_sendto+0x62c/0x7b0 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x130/0x200 net/socket.c:2199 do_syscall_64+0xd8/0x1f0 arch/x86/entry/common.c:83 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+0x5f6/0xc50 mm/slub.c:3888 kmalloc_reserve+0x13c/0x4a0 net/core/skbuff.c:577 __alloc_skb+0x35a/0x7c0 net/core/skbuff.c:668 alloc_skb include/linux/skbuff.h:1318 [inline] __ip_append_data+0x49ab/0x68c0 net/ipv4/ip_output.c:1128 ip_append_data+0x1e7/0x260 net/ipv4/ip_output.c:1365 raw_sendmsg+0x22b1/0x2690 net/ipv4/raw.c:648 inet_sendmsg+0x27b/0x2a0 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x274/0x3c0 net/socket.c:745 __sys_sendto+0x62c/0x7b0 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x130/0x200 net/socket.c:2199 do_syscall_64+0xd8/0x1f0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x6d/0x75CPU: 1 PID: 15709 Comm: syz-executor.7 Not tainted 6.8.0-11567-gb3603fcb79b1 #25Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014(CVE-2024-36927)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:net/mlx5e: Fix netif state handlingmlx5e_suspend cleans resources only if netif_device_present() returnstrue. However, mlx5e_resume changes the state of netif, viamlx5e_nic_enable, only if reg_state == NETREG_REGISTERED.In the below case, the above leads to NULL-ptr Oops[1] and memoryleaks:mlx5e_probe _mlx5e_resume  mlx5e_attach_netdev   mlx5e_nic_enable  &lt;-- netdev not reg, not calling netif_device_attach()  register_netdev &lt;-- failed for some reason.ERROR_FLOW: _mlx5e_suspend &lt;-- netif_device_present return false, resources aren&#39;t freed :(Hence, clean resources in this case as well.[1]BUG: kernel NULL pointer dereference, address: 0000000000000000PGD 0 P4D 0Oops: 0010 [#1] SMPCPU: 2 PID: 9345 Comm: test-ovs-ct-gen Not tainted 6.5.0_for_upstream_min_debug_2023_09_05_16_01 #1Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014RIP: 0010:0x0Code: Unable to access opcode bytes at0xffffffffffffffd6.RSP: 0018:ffff888178aaf758 EFLAGS: 00010246Call Trace: &lt;TASK&gt; ? __die+0x20/0x60 ? page_fault_oops+0x14c/0x3c0 ? exc_page_fault+0x75/0x140 ? asm_exc_page_fault+0x22/0x30 notifier_call_chain+0x35/0xb0 blocking_notifier_call_chain+0x3d/0x60 mlx5_blocking_notifier_call_chain+0x22/0x30 [mlx5_core] mlx5_core_uplink_netdev_event_replay+0x3e/0x60 [mlx5_core] mlx5_mdev_netdev_track+0x53/0x60 [mlx5_ib] mlx5_ib_roce_init+0xc3/0x340 [mlx5_ib] __mlx5_ib_add+0x34/0xd0 [mlx5_ib] mlx5r_probe+0xe1/0x210 [mlx5_ib] ? auxiliary_match_id+0x6a/0x90 auxiliary_bus_probe+0x38/0x80 ? driver_sysfs_add+0x51/0x80 really_probe+0xc9/0x3e0 ? driver_probe_device+0x90/0x90 __driver_probe_device+0x80/0x160 driver_probe_device+0x1e/0x90 __device_attach_driver+0x7d/0x100 bus_for_each_drv+0x80/0xd0 __device_attach+0xbc/0x1f0 bus_probe_device+0x86/0xa0 device_add+0x637/0x840 __auxiliary_device_add+0x3b/0xa0 add_adev+0xc9/0x140 [mlx5_core] mlx5_rescan_drivers_locked+0x22a/0x310 [mlx5_core] mlx5_register_device+0x53/0xa0 [mlx5_core] mlx5_init_one_devl_locked+0x5c4/0x9c0 [mlx5_core] mlx5_init_one+0x3b/0x60 [mlx5_core] probe_one+0x44c/0x730 [mlx5_core] local_pci_probe+0x3e/0x90 pci_device_probe+0xbf/0x210 ? kernfs_create_link+0x5d/0xa0 ? sysfs_do_create_link_sd+0x60/0xc0 really_probe+0xc9/0x3e0 ? driver_probe_device+0x90/0x90 __driver_probe_device+0x80/0x160 driver_probe_device+0x1e/0x90 __device_attach_driver+0x7d/0x100 bus_for_each_drv+0x80/0xd0 __device_attach+0xbc/0x1f0 pci_bus_add_device+0x54/0x80 pci_iov_add_virtfn+0x2e6/0x320 sriov_enable+0x208/0x420 mlx5_core_sriov_configure+0x9e/0x200 [mlx5_core] sriov_numvfs_store+0xae/0x1a0 kernfs_fop_write_iter+0x10c/0x1a0 vfs_write+0x291/0x3c0 ksys_write+0x5f/0xe0 do_syscall_64+0x3d/0x90 entry_SYSCALL_64_after_hwframe+0x46/0xb0 CR2: 0000000000000000 ---[ end trace 0000000000000000  ]---(CVE-2024-38608)In the Linux kernel, the following vulnerability has been resolved:ipv6: sr: fix invalid unregister error pathThe error path of seg6_init() is wrong in case CONFIG_IPV6_SEG6_LWTUNNELis not defined. In that case if seg6_hmac_init() fails, thegenl_unregister_family() isn&#39;t called.This issue exist since commit 46738b1317e1 (&#34;ipv6: sr: add option to controllwtunnel support&#34;), and commit 5559cea2d5aa (&#34;ipv6: sr: fix possibleuse-after-free and null-ptr-deref&#34;) replaced unregister_pernet_subsys()with genl_unregister_family() in this error path.(CVE-2024-38612)In the Linux kernel, the following vulnerability has been resolved:greybus: Fix use-after-free bug in gb_interface_release due to race condition.In gb_interface_create, &amp;intf-&gt;mode_switch_completion is bound withgb_interface_mode_switch_work. Then it will be started bygb_interface_request_mode_switch. Here is the relevant code.if (!queue_work(system_long_wq, &amp;intf-&gt;mode_switch_work)) {&#x9;...}If we call gb_interface_release to make cleanup, there may be anunfinished work. This function will call kfree to free the object&#34;intf&#34;. However, if gb_interface_mode_switch_work is scheduled torun after kfree, it may cause use-after-free error asgb_interface_mode_switch_work will use the object &#34;intf&#34;.The possible execution flow that may lead to the issue is as follows:CPU0                            CPU1                            |   gb_interface_create                            |   gb_interface_request_mode_switchgb_interface_release        |kfree(intf) (free)          |                            |   gb_interface_mode_switch_work                            |   mutex_lock(&amp;intf-&gt;mutex) (use)Fix it by canceling the work before kfree.(CVE-2024-39495)In the Linux kernel, the following vulnerability has been resolved:netns: Make get_net_ns() handle zero refcount netSyzkaller hit a warning:refcount_t: addition on 0; use-after-free.WARNING: CPU: 3 PID: 7890 at lib/refcount.c:25 refcount_warn_saturate+0xdf/0x1d0Modules linked in:CPU: 3 PID: 7890 Comm: tun Not tainted 6.10.0-rc3-00100-gcaa4f9578aba-dirty #310Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014RIP: 0010:refcount_warn_saturate+0xdf/0x1d0Code: 41 49 04 31 ff 89 de e8 9f 1e cd fe 84 db 75 9c e8 76 26 cd fe c6 05 b6 41 49 04 01 90 48 c7 c7 b8 8e 25 86 e8 d2 05 b5 fe 90 &lt;0f&gt; 0b 90 90 e9 79 ff ff ff e8 53 26 cd fe 0f b6 1RSP: 0018:ffff8881067b7da0 EFLAGS: 00010286RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c72acRDX: ffff8881026a2140 RSI: ffffffff811c72b5 RDI: 0000000000000001RBP: ffff8881067b7db0 R08: 0000000000000000 R09: 205b5d3730353139R10: 0000000000000000 R11: 205d303938375420 R12: ffff8881086500c4R13: ffff8881086500c4 R14: ffff8881086500b0 R15: ffff888108650040FS:  00007f5b2961a4c0(0000) GS:ffff88823bd00000(0000) knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000055d7ed36fd18 CR3: 00000001482f6000 CR4: 00000000000006f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: &lt;TASK&gt; ? show_regs+0xa3/0xc0 ? __warn+0xa5/0x1c0 ? refcount_warn_saturate+0xdf/0x1d0 ? report_bug+0x1fc/0x2d0 ? refcount_warn_saturate+0xdf/0x1d0 ? handle_bug+0xa1/0x110 ? exc_invalid_op+0x3c/0xb0 ? asm_exc_invalid_op+0x1f/0x30 ? __warn_printk+0xcc/0x140 ? __warn_printk+0xd5/0x140 ? refcount_warn_saturate+0xdf/0x1d0 get_net_ns+0xa4/0xc0 ? __pfx_get_net_ns+0x10/0x10 open_related_ns+0x5a/0x130 __tun_chr_ioctl+0x1616/0x2370 ? __sanitizer_cov_trace_switch+0x58/0xa0 ? __sanitizer_cov_trace_const_cmp2+0x1c/0x30 ? __pfx_tun_chr_ioctl+0x10/0x10 tun_chr_ioctl+0x2f/0x40 __x64_sys_ioctl+0x11b/0x160 x64_sys_call+0x1211/0x20d0 do_syscall_64+0x9e/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f5b28f165d7Code: b3 66 90 48 8b 05 b1 48 2d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d 81 48 2d 00 8RSP: 002b:00007ffc2b59c5e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f5b28f165d7RDX: 0000000000000000 RSI: 00000000000054e3 RDI: 0000000000000003RBP: 00007ffc2b59c650 R08: 00007f5b291ed8c0 R09: 00007f5b2961a4c0R10: 0000000029690010 R11: 0000000000000246 R12: 0000000000400730R13: 00007ffc2b59cf40 R14: 0000000000000000 R15: 0000000000000000 &lt;/TASK&gt;Kernel panic - not syncing: kernel: panic_on_warn set ...This is trigger as below:          ns0                                    ns1tun_set_iff() //dev is tun0   tun-&gt;dev = dev//ip link set tun0 netns ns1                                       put_net() //ref is 0__tun_chr_ioctl() //TUNGETDEVNETNS   net = dev_net(tun-&gt;dev);   open_related_ns(&amp;net-&gt;ns, get_net_ns); //ns1     get_net_ns()        get_net() //addition on 0Use maybe_get_net() in get_net_ns in case net&#39;s ref is zero to fix this(CVE-2024-40958)In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: During vport delete send async logout explicitlyDuring vport delete, it is observed that during unload we hit a crashbecause of stale entries in outstanding command array.  For all these staleI/O entries, eh_abort was issued and aborted (fast_fail_io = 2009h) butI/Os could not complete while vport delete is in process of deleting.  BUG: kernel NULL pointer dereference, address: 000000000000001c  #PF: supervisor read access in kernel mode  #PF: error_code(0x0000) - not-present page  PGD 0 P4D 0  Oops: 0000 [#1] PREEMPT SMP NOPTI  Workqueue: qla2xxx_wq qla_do_work [qla2xxx]  RIP: 0010:dma_direct_unmap_sg+0x51/0x1e0  RSP: 0018:ffffa1e1e150fc68 EFLAGS: 00010046  RAX: 0000000000000000 RBX: 0000000000000021 RCX: 0000000000000001  RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff8ce208a7a0d0  RBP: ffff8ce208a7a0d0 R08: 0000000000000000 R09: ffff8ce378aac9c8  R10: ffff8ce378aac8a0 R11: ffffa1e1e150f9d8 R12: 0000000000000000  R13: 0000000000000000 R14: ffff8ce378aac9c8 R15: 0000000000000000  FS:  0000000000000000(0000) GS:ffff8d217f000000(0000) knlGS:0000000000000000  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  CR2: 000000000000001c CR3: 0000002089acc000 CR4: 0000000000350ee0  Call Trace:  &lt;TASK&gt;  qla2xxx_qpair_sp_free_dma+0x417/0x4e0  ? qla2xxx_qpair_sp_compl+0x10d/0x1a0  ? qla2x00_status_entry+0x768/0x2830  ? newidle_balance+0x2f0/0x430  ? dequeue_entity+0x100/0x3c0  ? qla24xx_process_response_queue+0x6a1/0x19e0  ? __schedule+0x2d5/0x1140  ? qla_do_work+0x47/0x60  ? process_one_work+0x267/0x440  ? process_one_work+0x440/0x440  ? worker_thread+0x2d/0x3d0  ? process_one_work+0x440/0x440  ? kthread+0x156/0x180  ? set_kthread_struct+0x50/0x50  ? ret_from_fork+0x22/0x30  &lt;/TASK&gt;Send out async logout explicitly for all the ports during vport delete.(CVE-2024-42289)In the Linux kernel, the following vulnerability has been resolved:net: flow_dissector: use DEBUG_NET_WARN_ON_ONCEThe following splat is easy to reproduce upstream as well as in -stablekernels. Florian Westphal provided the following commit:  d1dab4f71d37 (&#34;net: add and use __skb_get_hash_symmetric_net&#34;)but this complementary fix has been also suggested by Willem de Bruijnand it can be easily backported to -stable kernel which consists inusing DEBUG_NET_WARN_ON_ONCE instead to silence the following splatgiven __skb_get_hash() is used by the nftables tracing infrastructure toto identify packets in traces.[69133.561393] ------------[ cut here ]------------[69133.561404] WARNING: CPU: 0 PID: 43576 at net/core/flow_dissector.c:1104 __skb_flow_dissect+0x134f/[...][69133.561944] CPU: 0 PID: 43576 Comm: socat Not tainted 6.10.0-rc7+ #379[69133.561959] RIP: 0010:__skb_flow_dissect+0x134f/0x2ad0[69133.561970] Code: 83 f9 04 0f 84 b3 00 00 00 45 85 c9 0f 84 aa 00 00 00 41 83 f9 02 0f 84 81 fc ffff 44 0f b7 b4 24 80 00 00 00 e9 8b f9 ff ff &lt;0f&gt; 0b e9 20 f3 ff ff 41 f6 c6 20 0f 84 e4 ef ff ff 48 8d 7b 12 e8[69133.561979] RSP: 0018:ffffc90000006fc0 EFLAGS: 00010246[69133.561988] RAX: 0000000000000000 RBX: ffffffff82f33e20 RCX: ffffffff81ab7e19[69133.561994] RDX: dffffc0000000000 RSI: ffffc90000007388 RDI: ffff888103a1b418[69133.562001] RBP: ffffc90000007310 R08: 0000000000000000 R09: 0000000000000000[69133.562007] R10: ffffc90000007388 R11: ffffffff810cface R12: ffff888103a1b400[69133.562013] R13: 0000000000000000 R14: ffffffff82f33e2a R15: ffffffff82f33e28[69133.562020] FS:  00007f40f7131740(0000) GS:ffff888390800000(0000) knlGS:0000000000000000[69133.562027] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033[69133.562033] CR2: 00007f40f7346ee0 CR3: 000000015d200001 CR4: 00000000001706f0[69133.562040] Call Trace:[69133.562044]  &lt;IRQ&gt;[69133.562049]  ? __warn+0x9f/0x1a0[ 1211.841384]  ? __skb_flow_dissect+0x107e/0x2860[...][ 1211.841496]  ? bpf_flow_dissect+0x160/0x160[ 1211.841753]  __skb_get_hash+0x97/0x280[ 1211.841765]  ? __skb_get_hash_symmetric+0x230/0x230[ 1211.841776]  ? mod_find+0xbf/0xe0[ 1211.841786]  ? get_stack_info_noinstr+0x12/0xe0[ 1211.841798]  ? bpf_ksym_find+0x56/0xe0[ 1211.841807]  ? __rcu_read_unlock+0x2a/0x70[ 1211.841819]  nft_trace_init+0x1b9/0x1c0 [nf_tables][ 1211.841895]  ? nft_trace_notify+0x830/0x830 [nf_tables][ 1211.841964]  ? get_stack_info+0x2b/0x80[ 1211.841975]  ? nft_do_chain_arp+0x80/0x80 [nf_tables][ 1211.842044]  nft_do_chain+0x79c/0x850 [nf_tables](CVE-2024-42321)In the Linux kernel, the following vulnerability has been resolved:mlxsw: spectrum_acl_erp: Fix object nesting warningACLs in Spectrum-2 and newer ASICs can reside in the algorithmic TCAM(A-TCAM) or in the ordinary circuit TCAM (C-TCAM). The former cancontain more ACLs (i.e., tc filters), but the number of masks in eachregion (i.e., tc chain) is limited.In order to mitigate the effects of the above limitation, the deviceallows filters to share a single mask if their masks only differ in upto 8 consecutive bits. For example, dst_ip/25 can be represented usingdst_ip/24 with a delta of 1 bit. The C-TCAM does not have a limit on thenumber of masks being used (and therefore does not support maskaggregation), but can contain a limited number of filters.The driver uses the &#34;objagg&#34; library to perform the mask aggregation bypassing it objects that consist of the filter&#39;s mask and whether thefilter is to be inserted into the A-TCAM or the C-TCAM since filters indifferent TCAMs cannot share a mask.The set of created objects is dependent on the insertion order of thefilters and is not necessarily optimal. Therefore, the driver willperiodically ask the library to compute a more optimal set (&#34;hints&#34;) bylooking at all the existing objects.When the library asks the driver whether two objects can be aggregatedthe driver only compares the provided masks and ignores the A-TCAM /C-TCAM indication. This is the right thing to do since the goal is tomove as many filters as possible to the A-TCAM. The driver also forbidstwo identical masks from being aggregated since this can only happen ifone was intentionally put in the C-TCAM to avoid a conflict in theA-TCAM.The above can result in the following set of hints:H1: {mask X, A-TCAM} -&gt; H2: {mask Y, A-TCAM} // X is Y + deltaH3: {mask Y, C-TCAM} -&gt; H4: {mask Z, A-TCAM} // Y is Z + deltaAfter getting the hints from the library the driver will start migratingfilters from one region to another while consulting the computed hintsand instructing the device to perform a lookup in both regions duringthe transition.Assuming a filter with mask X is being migrated into the A-TCAM in thenew region, the hints lookup will return H1. Since H2 is the parent ofH1, the library will try to find the object associated with it andcreate it if necessary in which case another hints lookup (recursive)will be performed. This hints lookup for {mask Y, A-TCAM} will eitherreturn H2 or H3 since the driver passes the library an object comparisonfunction that ignores the A-TCAM / C-TCAM indication.This can eventually lead to nested objects which are not supported bythe library [1].Fix by removing the object comparison function from both the driver andthe library as the driver was the only user. That way the lookup willonly return exact matches.I do not have a reliable reproducer that can reproduce the issue in atimely manner, but before the fix the issue would reproduce in severalminutes and with the fix it does not reproduce in over an hour.Note that the current usefulness of the hints is limited because theyinclude the C-TCAM indication and represent aggregation that cannotactually happen. This will be addressed in net-next.[1]WARNING: CPU: 0 PID: 153 at lib/objagg.c:170 objagg_obj_parent_assign+0xb5/0xd0Modules linked in:CPU: 0 PID: 153 Comm: kworker/0:18 Not tainted 6.9.0-rc6-custom-g70fbc2c1c38b #42Hardware name: Mellanox Technologies Ltd. MSN3700C/VMOD0008, BIOS 5.11 10/10/2018Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_workRIP: 0010:objagg_obj_parent_assign+0xb5/0xd0[...]Call Trace: &lt;TASK&gt; __objagg_obj_get+0x2bb/0x580 objagg_obj_get+0xe/0x80 mlxsw_sp_acl_erp_mask_get+0xb5/0xf0 mlxsw_sp_acl_atcam_entry_add+0xe8/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(CVE-2024-43880)In the Linux kernel, the following vulnerability has been resolved:gpio: prevent potential speculation leaks in gpio_device_get_desc()Userspace may trigger a speculative read of an address outside the gpiodescriptor array.Users can do that by calling gpio_ioctl() with an offset out of range.Offset is copied from user and then used as an array index to getthe gpio descriptor without sanitization in gpio_device_get_desc().This change ensures that the offset is sanitized by usingarray_index_nospec() to mitigate any possibility of speculativeinformation leaks.This bug was discovered and resolved using Coverity Static AnalysisSecurity Testing (SAST) by Synopsys, Inc.(CVE-2024-44931)In the Linux kernel, the following vulnerability has been resolved:driver core: Fix uevent_show() vs driver detach raceuevent_show() wants to de-reference dev-&gt;driver-&gt;name. There is no cleanway for a device attribute to de-reference dev-&gt;driver unless thatattribute is defined via (struct device_driver).dev_groups. Instead, theanti-pattern of taking the device_lock() in the attribute handler risksdeadlocks with code paths that remove device attributes while holdingthe lock.This deadlock is typically invisible to lockdep given the device_lock()is marked lockdep_set_novalidate_class(), but some subsystems allocate alocal lockdep key for @dev-&gt;mutex to reveal reports of the form: ====================================================== WARNING: possible circular locking dependency detected 6.10.0-rc7+ #275 Tainted: G           OE    N ------------------------------------------------------ modprobe/2374 is trying to acquire lock: ffff8c2270070de0 (kn-&gt;active#6){++++}-{0:0}, at: __kernfs_remove+0xde/0x220 but task is already holding lock: ffff8c22016e88f8 (&amp;cxl_root_key){+.+.}-{3:3}, at: device_release_driver_internal+0x39/0x210 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -&gt; #1 (&amp;cxl_root_key){+.+.}-{3:3}:        __mutex_lock+0x99/0xc30        uevent_show+0xac/0x130        dev_attr_show+0x18/0x40        sysfs_kf_seq_show+0xac/0xf0        seq_read_iter+0x110/0x450        vfs_read+0x25b/0x340        ksys_read+0x67/0xf0        do_syscall_64+0x75/0x190        entry_SYSCALL_64_after_hwframe+0x76/0x7e -&gt; #0 (kn-&gt;active#6){++++}-{0:0}:        __lock_acquire+0x121a/0x1fa0        lock_acquire+0xd6/0x2e0        kernfs_drain+0x1e9/0x200        __kernfs_remove+0xde/0x220        kernfs_remove_by_name_ns+0x5e/0xa0        device_del+0x168/0x410        device_unregister+0x13/0x60        devres_release_all+0xb8/0x110        device_unbind_cleanup+0xe/0x70        device_release_driver_internal+0x1c7/0x210        driver_detach+0x47/0x90        bus_remove_driver+0x6c/0xf0        cxl_acpi_exit+0xc/0x11 [cxl_acpi]        __do_sys_delete_module.isra.0+0x181/0x260        do_syscall_64+0x75/0x190        entry_SYSCALL_64_after_hwframe+0x76/0x7eThe observation though is that driver objects are typically much longerlived than device objects. It is reasonable to perform locklessde-reference of a @driver pointer even if it is racing detach from adevice. Given the infrequency of driver unregistration, usesynchronize_rcu() in module_remove_driver() to close any potentialraces.  It is potentially overkill to suffer synchronize_rcu() just tohandle the rare module removal racing uevent_show() event.Thanks to Tetsuo Handa for the debug analysis of the syzbot report [1].(CVE-2024-44952)In the Linux kernel, the following vulnerability has been resolved:bonding: fix xfrm real_dev null pointer dereferenceWe shouldn&#39;t set real_dev to NULL because packets can be in transit andxfrm might call xdo_dev_offload_ok() in parallel. All callbacks assumereal_dev is set. Example trace: kernel: BUG: unable to handle page fault for address: 0000000000001030 kernel: bond0: (slave eni0np1): making interface the new active one kernel: #PF: supervisor write access in kernel mode kernel: #PF: error_code(0x0002) - not-present page kernel: PGD 0 P4D 0 kernel: Oops: 0002 [#1] PREEMPT SMP kernel: CPU: 4 PID: 2237 Comm: ping Not tainted 6.7.7+ #12 kernel: Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 kernel: RIP: 0010:nsim_ipsec_offload_ok+0xc/0x20 [netdevsim] kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA kernel: Code: e0 0f 0b 48 83 7f 38 00 74 de 0f 0b 48 8b 47 08 48 8b 37 48 8b 78 40 e9 b2 e5 9a d7 66 90 0f 1f 44 00 00 48 8b 86 80 02 00 00 &lt;83&gt; 80 30 10 00 00 01 b8 01 00 00 00 c3 0f 1f 80 00 00 00 00 0f 1f kernel: bond0: (slave eni0np1): making interface the new active one kernel: RSP: 0018:ffffabde81553b98 EFLAGS: 00010246 kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA kernel: kernel: RAX: 0000000000000000 RBX: ffff9eb404e74900 RCX: ffff9eb403d97c60 kernel: RDX: ffffffffc090de10 RSI: ffff9eb404e74900 RDI: ffff9eb3c5de9e00 kernel: RBP: ffff9eb3c0a42000 R08: 0000000000000010 R09: 0000000000000014 kernel: R10: 7974203030303030 R11: 3030303030303030 R12: 0000000000000000 kernel: R13: ffff9eb3c5de9e00 R14: ffffabde81553cc8 R15: ffff9eb404c53000 kernel: FS:  00007f2a77a3ad00(0000) GS:ffff9eb43bd00000(0000) knlGS:0000000000000000 kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 kernel: CR2: 0000000000001030 CR3: 00000001122ab000 CR4: 0000000000350ef0 kernel: bond0: (slave eni0np1): making interface the new active one kernel: Call Trace: kernel:  &lt;TASK&gt; kernel:  ? __die+0x1f/0x60 kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA kernel:  ? page_fault_oops+0x142/0x4c0 kernel:  ? do_user_addr_fault+0x65/0x670 kernel:  ? kvm_read_and_reset_apf_flags+0x3b/0x50 kernel: bond0: (slave eni0np1): making interface the new active one kernel:  ? exc_page_fault+0x7b/0x180 kernel:  ? asm_exc_page_fault+0x22/0x30 kernel:  ? nsim_bpf_uninit+0x50/0x50 [netdevsim] kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA kernel:  ? nsim_ipsec_offload_ok+0xc/0x20 [netdevsim] kernel: bond0: (slave eni0np1): making interface the new active one kernel:  bond_ipsec_offload_ok+0x7b/0x90 [bonding] kernel:  xfrm_output+0x61/0x3b0 kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA kernel:  ip_push_pending_frames+0x56/0x80(CVE-2024-44989)In the Linux kernel, the following vulnerability has been resolved:bonding: fix null pointer deref in bond_ipsec_offload_okWe must check if there is an active slave before dereferencing the pointer.(CVE-2024-44990)In the Linux kernel, the following vulnerability has been resolved:dmaengine: altera-msgdma: properly free descriptor in msgdma_free_descriptorRemove list_del call in msgdma_chan_desc_cleanup, this should be the roleof msgdma_free_descriptor. In consequence replace list_add_tail withlist_move_tail in msgdma_free_descriptor.This fixes the path:   msgdma_free_chan_resources -&gt; msgdma_free_descriptors -&gt;   msgdma_free_desc_list -&gt; msgdma_free_descriptorwhich does not correctly free the descriptors as first nodes were notremoved from the list.(CVE-2024-46716)In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Stop amdgpu_dm initialize when stream nums greater than 6[Why]Coverity reports OVERRUN warning. Should abort amdgpu_dminitialize.[How]Return failure to amdgpu_dm_init.(CVE-2024-46817)In the Linux kernel, the following vulnerability has been resolved:arm64: acpi: Harden get_cpu_for_acpi_id() against missing CPU entryIn a review discussion of the changes to support vCPU hotplug wherea check was added on the GICC being enabled if was online, it wasnoted that there is need to map back to the cpu and use that to indexinto a cpumask. As such, a valid ID is needed.If an MPIDR check fails in acpi_map_gic_cpu_interface() it is possiblefor the entry in cpu_madt_gicc[cpu] == NULL.  This function wouldthen cause a NULL pointer dereference.   Whilst a path to triggerthis has not been established, harden this caller against thepossibility.(CVE-2024-46822)In the Linux kernel, the following vulnerability has been resolved:platform/x86: panasonic-laptop: Fix SINF array out of bounds accessesThe panasonic laptop code in various places uses the SINF array with indexvalues of 0 - SINF_CUR_BRIGHT(0x0d) without checking that the SINF arrayis big enough.Not all panasonic laptops have this many SINF array entries, for examplethe Toughbook CF-18 model only has 10 SINF array entries. So it onlysupports the AC+DC brightness entries and mute.Check that the SINF array has a minimum size which covers all AC+DCbrightness entries and refuse to load if the SINF array is smaller.For higher SINF indexes hide the sysfs attributes when the SINF arraydoes not contain an entry for that attribute, avoiding show()/store()accessing the array out of bounds and add bounds checking to the probe()and resume() code accessing these.(CVE-2024-46859)In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Avoid overflow from uint32_t to uint8_t[WHAT &amp; HOW]dmub_rb_cmd&#39;s ramping_boundary has size of uint8_t and it is assigned0xFFFF. Fix it by changing it to uint8_t with value of 0xFF.This fixes 2 INTEGER_OVERFLOW issues reported by Coverity.(CVE-2024-47661)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="bpftool" release="233.0.0.132.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-233.0.0.132.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="233.0.0.132.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-233.0.0.132.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="233.0.0.132.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-233.0.0.132.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="233.0.0.132.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-233.0.0.132.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="233.0.0.132.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-233.0.0.132.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="233.0.0.132.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-233.0.0.132.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="233.0.0.132.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-233.0.0.132.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="233.0.0.132.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-233.0.0.132.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="233.0.0.132.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-233.0.0.132.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="233.0.0.132.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-233.0.0.132.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="233.0.0.132.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-233.0.0.132.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="233.0.0.132.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-233.0.0.132.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="233.0.0.132.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-233.0.0.132.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="233.0.0.132.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-233.0.0.132.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="233.0.0.132.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-233.0.0.132.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="233.0.0.132.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-233.0.0.132.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="233.0.0.132.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-233.0.0.132.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="233.0.0.132.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-233.0.0.132.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="233.0.0.132.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-233.0.0.132.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="233.0.0.132.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-233.0.0.132.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="233.0.0.132.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-233.0.0.132.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="233.0.0.132.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-233.0.0.132.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="233.0.0.132.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-233.0.0.132.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="233.0.0.132.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-233.0.0.132.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="233.0.0.132.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-233.0.0.132.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="233.0.0.132.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-233.0.0.132.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="233.0.0.132.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-233.0.0.132.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="233.0.0.132.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-233.0.0.132.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="233.0.0.132.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-233.0.0.132.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="233.0.0.132.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-233.0.0.132.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2299</id>
          <title>An update for jetty is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-10-25"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-26048" id="CVE-2023-26048" title="CVE-2023-26048" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-36479" id="CVE-2023-36479" title="CVE-2023-36479" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40167" id="CVE-2023-40167" title="CVE-2023-40167" type="cve"></reference>
          </references>
          <description>Jetty is a java based web server and servlet engine. In affected versions servlets with multipart support (e.g. annotated with `@MultipartConfig`) that call `HttpServletRequest.getParameter()` or `HttpServletRequest.getParts()` may cause `OutOfMemoryError` when the client sends a multipart request with a part that has a name but no filename and very large content. This happens even with the default settings of `fileSizeThreshold=0` which should stream the whole part content to disk. An attacker client may send a large multipart request and cause the server to throw `OutOfMemoryError`. However, the server may be able to recover after the `OutOfMemoryError` and continue its service -- although it may take some time. This issue has been patched in versions 9.4.51, 10.0.14, and 11.0.14. Users are advised to upgrade. Users unable to upgrade may set the multipart parameter `maxRequestSize` which must be set to a non-negative value, so the whole multipart content is limited (although still read into memory).(CVE-2023-26048)Eclipse Jetty Canonical Repository is the canonical repository for the Jetty project. Users of the CgiServlet with a very specific command structure may have the wrong command executed. If a user sends a request to a org.eclipse.jetty.servlets.CGI Servlet for a binary with a space in its name, the servlet will escape the command by wrapping it in quotation marks. This wrapped command, plus an optional command prefix, will then be executed through a call to Runtime.exec. If the original binary name provided by the user contains a quotation mark followed by a space, the resulting command line will contain multiple tokens instead of one. This issue was patched in version 9.4.52, 10.0.16, 11.0.16 and 12.0.0-beta2.(CVE-2023-36479)Jetty is a Java based web server and servlet engine. Prior to versions 9.4.52, 10.0.16, 11.0.16, and 12.0.1, Jetty accepts the `+` character proceeding the content-length value in a HTTP/1 header field.  This is more permissive than allowed by the RFC and other servers routinely reject such requests with 400 responses.  There is no known exploit scenario, but it is conceivable that request smuggling could result if jetty is used in combination with a server that does not close the connection after sending such a 400 response. Versions 9.4.52, 10.0.16, 11.0.16, and 12.0.1 contain a patch for this issue. There is no workaround as there is no known exploit scenario.(CVE-2023-40167)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="jetty" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-alpn-client" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-alpn-client-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-alpn-server" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-alpn-server-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-annotations" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-annotations-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-ant" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-ant-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-cdi" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-cdi-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-client" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-client-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-continuation" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-continuation-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-deploy" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-deploy-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-fcgi-client" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-fcgi-client-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-fcgi-server" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-fcgi-server-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-http" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-http-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-http-spi" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-http-spi-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-http2-client" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-http2-client-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-http2-common" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-http2-common-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-http2-hpack" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-http2-hpack-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-http2-http-client-transport" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-http2-http-client-transport-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-http2-server" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-http2-server-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-httpservice" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-httpservice-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-infinispan" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-infinispan-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-io" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-io-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-jaas" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-jaas-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-jaspi" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-jaspi-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-javadoc" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-javadoc-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-javax-websocket-client-impl" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-javax-websocket-client-impl-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-javax-websocket-server-impl" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-javax-websocket-server-impl-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-jmx" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-jmx-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-jndi" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-jndi-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-jsp" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-jsp-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-jspc-maven-plugin" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-jspc-maven-plugin-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-jstl" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-jstl-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-maven-plugin" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-maven-plugin-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-nosql" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-nosql-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-osgi-alpn" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-osgi-alpn-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-osgi-boot" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-osgi-boot-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-osgi-boot-jsp" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-osgi-boot-jsp-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-osgi-boot-warurl" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-osgi-boot-warurl-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-plus" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-plus-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-project" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-project-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-proxy" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-proxy-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-quickstart" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-quickstart-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-rewrite" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-rewrite-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-security" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-security-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-server" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-server-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-servlet" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-servlet-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-servlets" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-servlets-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-spring" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-spring-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-start" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-start-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-unixsocket" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-unixsocket-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-util" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-util-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-util-ajax" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-util-ajax-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-webapp" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-webapp-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-websocket-api" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-websocket-api-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-websocket-client" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-websocket-client-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-websocket-common" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-websocket-common-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-websocket-server" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-websocket-server-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-websocket-servlet" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-websocket-servlet-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-xml" release="7.oe2203sp4" version="9.4.16">
                         <filename>jetty-xml-9.4.16-7.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2301</id>
          <title>An update for edk2 is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-10-25"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45236" id="CVE-2023-45236" title="CVE-2023-45236" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45237" id="CVE-2023-45237" title="CVE-2023-45237" type="cve"></reference>
          </references>
          <description> EDK2&#39;s Network Package is susceptible to a predictable TCP Initial Sequence Number. This vulnerability can be exploited by an attacker to gain unauthorized access and potentially lead to a loss of Confidentiality.(CVE-2023-45236) EDK2&#39;s Network Package is susceptible to a predictable TCP Initial Sequence Number. This vulnerability can be exploited by an attacker to gain unauthorized access and potentially lead to a loss of Confidentiality.(CVE-2023-45237)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="edk2-debuginfo" release="22.oe2203sp4" version="202011">
                         <filename>edk2-debuginfo-202011-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="edk2-debugsource" release="22.oe2203sp4" version="202011">
                         <filename>edk2-debugsource-202011-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="edk2-devel" release="22.oe2203sp4" version="202011">
                         <filename>edk2-devel-202011-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-aarch64" release="22.oe2203sp4" version="202011">
                         <filename>edk2-aarch64-202011-22.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-help" release="22.oe2203sp4" version="202011">
                         <filename>edk2-help-202011-22.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-ovmf" release="22.oe2203sp4" version="202011">
                         <filename>edk2-ovmf-202011-22.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-edk2-devel" release="22.oe2203sp4" version="202011">
                         <filename>python3-edk2-devel-202011-22.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-debuginfo" release="22.oe2203sp4" version="202011">
                         <filename>edk2-debuginfo-202011-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-debugsource" release="22.oe2203sp4" version="202011">
                         <filename>edk2-debugsource-202011-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-devel" release="22.oe2203sp4" version="202011">
                         <filename>edk2-devel-202011-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2305</id>
          <title>An update for freeimage is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-11-01"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-24292" id="CVE-2020-24292" title="CVE-2020-24292" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-24293" id="CVE-2020-24293" title="CVE-2020-24293" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-24295" id="CVE-2020-24295" title="CVE-2020-24295" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33367" id="CVE-2021-33367" title="CVE-2021-33367" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-40263" id="CVE-2021-40263" title="CVE-2021-40263" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-40266" id="CVE-2021-40266" title="CVE-2021-40266" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-47995" id="CVE-2023-47995" title="CVE-2023-47995" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-47997" id="CVE-2023-47997" title="CVE-2023-47997" type="cve"></reference>
          </references>
          <description>Buffer Overflow vulnerability in load function in PluginICO.cpp in FreeImage 3.19.0 [r1859] allows remote attackers to run arbitrary code via opening of crafted ico file.(CVE-2020-24292)Buffer Overflow vulnerability in psdThumbnail::Read in PSDParser.cpp in FreeImage 3.19.0 [r1859] allows remote attackers to run arbitrary code via opening of crafted psd file.(CVE-2020-24293)Buffer Overflow vulnerability in PSDParser.cpp::ReadImageLine() in FreeImage 3.19.0 [r1859] allows remote attackers to ru narbitrary code via use of crafted psd file.(CVE-2020-24295)Buffer Overflow vulnerability in Freeimage v3.18.0 allows attacker to cause a denial of service via a crafted JXR file.(CVE-2021-33367)A heap overflow vulnerability in FreeImage 1.18.0 via the ofLoad function in PluginTIFF.cpp.(CVE-2021-40263)FreeImage before 1.18.0, ReadPalette function in PluginTIFF.cpp is vulnerabile to null pointer dereference.(CVE-2021-40266)Memory Allocation with Excessive Size Value discovered in BitmapAccess.cpp::FreeImage_AllocateBitmap in FreeImage 3.18.0 allows attackers to cause a denial of service.(CVE-2023-47995)An issue discovered in BitmapAccess.cpp::FreeImage_AllocateBitmap in FreeImage 3.18.0 leads to an infinite loop and allows attackers to cause a denial of service.(CVE-2023-47997)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="freeimage" release="11.oe2203sp4" version="3.18.0">
                         <filename>freeimage-3.18.0-11.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="freeimage-debuginfo" release="11.oe2203sp4" version="3.18.0">
                         <filename>freeimage-debuginfo-3.18.0-11.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="freeimage-debugsource" release="11.oe2203sp4" version="3.18.0">
                         <filename>freeimage-debugsource-3.18.0-11.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="freeimage-devel" release="11.oe2203sp4" version="3.18.0">
                         <filename>freeimage-devel-3.18.0-11.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freeimage" release="11.oe2203sp4" version="3.18.0">
                         <filename>freeimage-3.18.0-11.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freeimage-debuginfo" release="11.oe2203sp4" version="3.18.0">
                         <filename>freeimage-debuginfo-3.18.0-11.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freeimage-debugsource" release="11.oe2203sp4" version="3.18.0">
                         <filename>freeimage-debugsource-3.18.0-11.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freeimage-devel" release="11.oe2203sp4" version="3.18.0">
                         <filename>freeimage-devel-3.18.0-11.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2306</id>
          <title>An update for motif is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-11-01"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-44617" id="CVE-2022-44617" title="CVE-2022-44617" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-46285" id="CVE-2022-46285" title="CVE-2022-46285" type="cve"></reference>
          </references>
          <description>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="motif" release="4.oe2203sp4" version="2.3.8">
                         <filename>motif-2.3.8-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="motif-debuginfo" release="4.oe2203sp4" version="2.3.8">
                         <filename>motif-debuginfo-2.3.8-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="motif-debugsource" release="4.oe2203sp4" version="2.3.8">
                         <filename>motif-debugsource-2.3.8-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="motif-devel" release="4.oe2203sp4" version="2.3.8">
                         <filename>motif-devel-2.3.8-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="motif-help" release="4.oe2203sp4" version="2.3.8">
                         <filename>motif-help-2.3.8-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="motif" release="4.oe2203sp4" version="2.3.8">
                         <filename>motif-2.3.8-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="motif-debuginfo" release="4.oe2203sp4" version="2.3.8">
                         <filename>motif-debuginfo-2.3.8-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="motif-debugsource" release="4.oe2203sp4" version="2.3.8">
                         <filename>motif-debugsource-2.3.8-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="motif-devel" release="4.oe2203sp4" version="2.3.8">
                         <filename>motif-devel-2.3.8-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="motif-help" release="4.oe2203sp4" version="2.3.8">
                         <filename>motif-help-2.3.8-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2309</id>
          <title>An update for squid is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-11-01"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45802" id="CVE-2024-45802" title="CVE-2024-45802" type="cve"></reference>
          </references>
          <description>Squid is an open source caching proxy for the Web supporting HTTP, HTTPS, FTP, and more. Due to Input Validation, Premature Release of Resource During Expected Lifetime, and Missing Release of Resource after Effective Lifetime bugs, Squid is vulnerable to Denial of Service attacks by a trusted server against all clients using the proxy. This bug is fixed in the default build configuration of Squid version 6.10.(CVE-2024-45802)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="7" arch="aarch64" name="squid" release="27.oe2203sp4" version="4.9">
                         <filename>squid-4.9-27.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="squid-debuginfo" release="27.oe2203sp4" version="4.9">
                         <filename>squid-debuginfo-4.9-27.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="squid-debugsource" release="27.oe2203sp4" version="4.9">
                         <filename>squid-debugsource-4.9-27.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="squid" release="27.oe2203sp4" version="4.9">
                         <filename>squid-4.9-27.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="squid-debuginfo" release="27.oe2203sp4" version="4.9">
                         <filename>squid-debuginfo-4.9-27.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="squid-debugsource" release="27.oe2203sp4" version="4.9">
                         <filename>squid-debugsource-4.9-27.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2310</id>
          <title>An update for ghostscript is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2024-11-01"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46953" id="CVE-2024-46953" title="CVE-2024-46953" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46956" id="CVE-2024-46956" title="CVE-2024-46956" type="cve"></reference>
          </references>
          <description>VUL-0: CVE-2024-46953: ghostscript: An integer overflow when parsing the page format results in path truncation, path traversal, code execution(CVE-2024-46953)VUL-0: CVE-2024-46956: ghostscript: Arbitrary code execution via out of bounds data access in filenameforall(CVE-2024-46956)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="ghostscript" release="14.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-9.55.0-14.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ghostscript-debuginfo" release="14.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-debuginfo-9.55.0-14.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ghostscript-debugsource" release="14.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-debugsource-9.55.0-14.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ghostscript-devel" release="14.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-devel-9.55.0-14.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ghostscript-tools-dvipdf" release="14.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-tools-dvipdf-9.55.0-14.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="ghostscript-help" release="14.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-help-9.55.0-14.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript" release="14.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-9.55.0-14.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript-debuginfo" release="14.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-debuginfo-9.55.0-14.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript-debugsource" release="14.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-debugsource-9.55.0-14.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript-devel" release="14.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-devel-9.55.0-14.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript-tools-dvipdf" release="14.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-tools-dvipdf-9.55.0-14.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2311</id>
          <title>An update for expat is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-11-01"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50602" id="CVE-2024-50602" title="CVE-2024-50602" type="cve"></reference>
          </references>
          <description>An issue was discovered in libexpat before 2.6.4. There is a crash within the XML_ResumeParser function because XML_StopParser can stop/suspend an unstarted parser.(CVE-2024-50602)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="expat" release="14.oe2203sp4" version="2.4.1">
                         <filename>expat-2.4.1-14.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="expat-debuginfo" release="14.oe2203sp4" version="2.4.1">
                         <filename>expat-debuginfo-2.4.1-14.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="expat-debugsource" release="14.oe2203sp4" version="2.4.1">
                         <filename>expat-debugsource-2.4.1-14.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="expat-devel" release="14.oe2203sp4" version="2.4.1">
                         <filename>expat-devel-2.4.1-14.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="expat-help" release="14.oe2203sp4" version="2.4.1">
                         <filename>expat-help-2.4.1-14.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="expat" release="14.oe2203sp4" version="2.4.1">
                         <filename>expat-2.4.1-14.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="expat-debuginfo" release="14.oe2203sp4" version="2.4.1">
                         <filename>expat-debuginfo-2.4.1-14.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="expat-debugsource" release="14.oe2203sp4" version="2.4.1">
                         <filename>expat-debugsource-2.4.1-14.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="expat-devel" release="14.oe2203sp4" version="2.4.1">
                         <filename>expat-devel-2.4.1-14.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2315</id>
          <title>An update for xorg-x11-server is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-11-01"></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="33.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-1.20.11-33.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-Xdmx" release="33.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-Xdmx-1.20.11-33.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-Xephyr" release="33.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-Xephyr-1.20.11-33.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-Xnest" release="33.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-Xnest-1.20.11-33.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-Xvfb" release="33.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-Xvfb-1.20.11-33.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-common" release="33.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-common-1.20.11-33.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-debuginfo" release="33.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-debuginfo-1.20.11-33.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-debugsource" release="33.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-debugsource-1.20.11-33.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-devel" release="33.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-devel-1.20.11-33.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="xorg-x11-server-help" release="33.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-help-1.20.11-33.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="xorg-x11-server-source" release="33.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-source-1.20.11-33.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server" release="33.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-1.20.11-33.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xdmx" release="33.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-Xdmx-1.20.11-33.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xephyr" release="33.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-Xephyr-1.20.11-33.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xnest" release="33.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-Xnest-1.20.11-33.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xvfb" release="33.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-Xvfb-1.20.11-33.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-common" release="33.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-common-1.20.11-33.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-debuginfo" release="33.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-debuginfo-1.20.11-33.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-debugsource" release="33.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-debugsource-1.20.11-33.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-devel" release="33.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-devel-1.20.11-33.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2321</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2024-11-01"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48916" id="CVE-2022-48916" title="CVE-2022-48916" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48952" id="CVE-2022-48952" title="CVE-2022-48952" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52917" id="CVE-2023-52917" title="CVE-2023-52917" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52918" id="CVE-2023-52918" title="CVE-2023-52918" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35878" id="CVE-2024-35878" title="CVE-2024-35878" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35990" id="CVE-2024-35990" title="CVE-2024-35990" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36286" id="CVE-2024-36286" title="CVE-2024-36286" 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-38635" id="CVE-2024-38635" title="CVE-2024-38635" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38667" id="CVE-2024-38667" title="CVE-2024-38667" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42152" id="CVE-2024-42152" title="CVE-2024-42152" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42301" id="CVE-2024-42301" title="CVE-2024-42301" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42315" id="CVE-2024-42315" title="CVE-2024-42315" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43841" id="CVE-2024-43841" title="CVE-2024-43841" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43858" id="CVE-2024-43858" title="CVE-2024-43858" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43867" id="CVE-2024-43867" title="CVE-2024-43867" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43871" id="CVE-2024-43871" title="CVE-2024-43871" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43894" id="CVE-2024-43894" title="CVE-2024-43894" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45009" id="CVE-2024-45009" title="CVE-2024-45009" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46675" id="CVE-2024-46675" title="CVE-2024-46675" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46689" id="CVE-2024-46689" title="CVE-2024-46689" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46722" id="CVE-2024-46722" title="CVE-2024-46722" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46724" id="CVE-2024-46724" title="CVE-2024-46724" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46757" id="CVE-2024-46757" title="CVE-2024-46757" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46802" id="CVE-2024-46802" title="CVE-2024-46802" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46830" id="CVE-2024-46830" title="CVE-2024-46830" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46853" id="CVE-2024-46853" title="CVE-2024-46853" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47667" id="CVE-2024-47667" title="CVE-2024-47667" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47669" id="CVE-2024-47669" title="CVE-2024-47669" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47684" id="CVE-2024-47684" title="CVE-2024-47684" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47685" id="CVE-2024-47685" title="CVE-2024-47685" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47692" id="CVE-2024-47692" title="CVE-2024-47692" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47695" id="CVE-2024-47695" title="CVE-2024-47695" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47698" id="CVE-2024-47698" title="CVE-2024-47698" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47709" id="CVE-2024-47709" title="CVE-2024-47709" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47710" id="CVE-2024-47710" title="CVE-2024-47710" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47720" id="CVE-2024-47720" title="CVE-2024-47720" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47735" id="CVE-2024-47735" title="CVE-2024-47735" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47737" id="CVE-2024-47737" title="CVE-2024-47737" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47757" id="CVE-2024-47757" title="CVE-2024-47757" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49866" id="CVE-2024-49866" title="CVE-2024-49866" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49867" id="CVE-2024-49867" title="CVE-2024-49867" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49868" id="CVE-2024-49868" title="CVE-2024-49868" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49875" id="CVE-2024-49875" title="CVE-2024-49875" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49892" id="CVE-2024-49892" title="CVE-2024-49892" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49894" id="CVE-2024-49894" title="CVE-2024-49894" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49895" id="CVE-2024-49895" title="CVE-2024-49895" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49900" id="CVE-2024-49900" title="CVE-2024-49900" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49902" id="CVE-2024-49902" title="CVE-2024-49902" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49903" id="CVE-2024-49903" title="CVE-2024-49903" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49911" id="CVE-2024-49911" title="CVE-2024-49911" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49927" id="CVE-2024-49927" title="CVE-2024-49927" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49959" id="CVE-2024-49959" title="CVE-2024-49959" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49965" id="CVE-2024-49965" title="CVE-2024-49965" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49966" id="CVE-2024-49966" title="CVE-2024-49966" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49969" id="CVE-2024-49969" title="CVE-2024-49969" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49974" id="CVE-2024-49974" title="CVE-2024-49974" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49985" id="CVE-2024-49985" title="CVE-2024-49985" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50025" id="CVE-2024-50025" title="CVE-2024-50025" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50036" id="CVE-2024-50036" title="CVE-2024-50036" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50046" id="CVE-2024-50046" title="CVE-2024-50046" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50049" id="CVE-2024-50049" title="CVE-2024-50049" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:iommu/vt-d: Fix double list_add when enabling VMD in scalable modeWhen enabling VMD and IOMMU scalable mode, the following kernel paniccall trace/kernel log is shown in Eagle Stream platform (Sapphire RapidsCPU) during booting:pci 0000:59:00.5: Adding to iommu group 42...vmd 0000:59:00.5: PCI host bridge to bus 10000:80pci 10000:80:01.0: [8086:352a] type 01 class 0x060400pci 10000:80:01.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit]pci 10000:80:01.0: enabling Extended Tagspci 10000:80:01.0: PME# supported from D0 D3hot D3coldpci 10000:80:01.0: DMAR: Setup RID2PASID failedpci 10000:80:01.0: Failed to add to iommu group 42: -16pci 10000:80:03.0: [8086:352b] type 01 class 0x060400pci 10000:80:03.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit]pci 10000:80:03.0: enabling Extended Tagspci 10000:80:03.0: PME# supported from D0 D3hot D3cold------------[ cut here ]------------kernel BUG at lib/list_debug.c:29!invalid opcode: 0000 [#1] PREEMPT SMP NOPTICPU: 0 PID: 7 Comm: kworker/0:1 Not tainted 5.17.0-rc3+ #7Hardware name: Lenovo ThinkSystem SR650V3/SB27A86647, BIOS ESE101Y-1.00 01/13/2022Workqueue: events work_for_cpu_fnRIP: 0010:__list_add_valid.cold+0x26/0x3fCode: 9a 4a ab ff 4c 89 c1 48 c7 c7 40 0c d9 9e e8 b9 b1 fe ff 0f      0b 48 89 f2 4c 89 c1 48 89 fe 48 c7 c7 f0 0c d9 9e e8 a2 b1      fe ff &lt;0f&gt; 0b 48 89 d1 4c 89 c6 4c 89 ca 48 c7 c7 98 0c d9      9e e8 8b b1 feRSP: 0000:ff5ad434865b3a40 EFLAGS: 00010246RAX: 0000000000000058 RBX: ff4d61160b74b880 RCX: ff4d61255e1fffa8RDX: 0000000000000000 RSI: 00000000fffeffff RDI: ffffffff9fd34f20RBP: ff4d611d8e245c00 R08: 0000000000000000 R09: ff5ad434865b3888R10: ff5ad434865b3880 R11: ff4d61257fdc6fe8 R12: ff4d61160b74b8a0R13: ff4d61160b74b8a0 R14: ff4d611d8e245c10 R15: ff4d611d8001ba70FS:  0000000000000000(0000) GS:ff4d611d5ea00000(0000) knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: ff4d611fa1401000 CR3: 0000000aa0210001 CR4: 0000000000771ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400PKRU: 55555554Call Trace: &lt;TASK&gt; intel_pasid_alloc_table+0x9c/0x1d0 dmar_insert_one_dev_info+0x423/0x540 ? device_to_iommu+0x12d/0x2f0 intel_iommu_attach_device+0x116/0x290 __iommu_attach_device+0x1a/0x90 iommu_group_add_device+0x190/0x2c0 __iommu_probe_device+0x13e/0x250 iommu_probe_device+0x24/0x150 iommu_bus_notifier+0x69/0x90 blocking_notifier_call_chain+0x5a/0x80 device_add+0x3db/0x7b0 ? arch_memremap_can_ram_remap+0x19/0x50 ? memremap+0x75/0x140 pci_device_add+0x193/0x1d0 pci_scan_single_device+0xb9/0xf0 pci_scan_slot+0x4c/0x110 pci_scan_child_bus_extend+0x3a/0x290 vmd_enable_domain.constprop.0+0x63e/0x820 vmd_probe+0x163/0x190 local_pci_probe+0x42/0x80 work_for_cpu_fn+0x13/0x20 process_one_work+0x1e2/0x3b0 worker_thread+0x1c4/0x3a0 ? rescuer_thread+0x370/0x370 kthread+0xc7/0xf0 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 &lt;/TASK&gt;Modules linked in:---[ end trace 0000000000000000 ]---...Kernel panic - not syncing: Fatal exceptionKernel Offset: 0x1ca00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)---[ end Kernel panic - not syncing: Fatal exception ]---The following &#39;lspci&#39; output shows devices &#39;10000:80:*&#39; are subdevices ofthe VMD device 0000:59:00.5:  $ lspci  ...  0000:59:00.5 RAID bus controller: Intel Corporation Volume Management Device NVMe RAID Controller (rev 20)  ...  10000:80:01.0 PCI bridge: Intel Corporation Device 352a (rev 03)  10000:80:03.0 PCI bridge: Intel Corporation Device 352b (rev 03)  10000:80:05.0 PCI bridge: Intel Corporation Device 352c (rev 03)  10000:80:07.0 PCI bridge: Intel Corporation Device 352d (rev 03)  10000:81:00.0 Non-Volatile memory controller: Intel Corporation NVMe Datacenter SSD [3DNAND, Beta Rock Controller]  10000:82:00---truncated---(CVE-2022-48916)In the Linux kernel, the following vulnerability has been resolved:  PCI: mt7621: Add sentinel to quirks table  Current driver is missing a sentinel in the struct soc_device_attribute array, which causes an oops when assessed by the soc_device_match(mt7621_pcie_quirks_match) call.  This was only exposed once the CONFIG_SOC_MT7621 mt7621 soc_dev_attr was fixed to register the SOC as a device, in:  commit 7c18b64bba3b (&#34;mips: ralink: mt7621: do not use kzalloc too early&#34;)  Fix it by adding the required sentinel.(CVE-2022-48952)In the Linux kernel, the following vulnerability has been resolved:  ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir()  The debugfs_create_dir() function returns error pointers. It never returns NULL. So use IS_ERR() to check it.(CVE-2023-52917)In the Linux kernel, the following vulnerability has been resolved:  media: pci: cx23885: check cx23885_vdev_init() return  cx23885_vdev_init() can return a NULL pointer, but that pointer is used in the next line without a check.  Add a NULL pointer check and go to the error unwind if it is NULL.(CVE-2023-52918)In the Linux kernel, the following vulnerability has been resolved:of: module: prevent NULL pointer dereference in vsnprintf()In of_modalias(), we can get passed the str and len parameters which wouldcause a kernel oops in vsnprintf() since it only allows passing a NULL ptrwhen the length is also 0. Also, we need to filter out the negative valuesof the len parameter as these will result in a really huge buffer sincesnprintf() takes size_t parameter while ours is ssize_t...Found by Linux Verification Center (linuxtesting.org) with the Svace staticanalysis tool.(CVE-2024-35878)In the Linux kernel, the following vulnerability has been resolved:dma: xilinx_dpdma: Fix lockingThere are several places where either chan-&gt;lock or chan-&gt;vchan.lock wasnot held. Add appropriate locking. This fixes lockdep warnings like[   31.077578] ------------[ cut here ]------------[   31.077831] WARNING: CPU: 2 PID: 40 at drivers/dma/xilinx/xilinx_dpdma.c:834 xilinx_dpdma_chan_queue_transfer+0x274/0x5e0[   31.077953] Modules linked in:[   31.078019] CPU: 2 PID: 40 Comm: kworker/u12:1 Not tainted 6.6.20+ #98[   31.078102] Hardware name: xlnx,zynqmp (DT)[   31.078169] Workqueue: events_unbound deferred_probe_work_func[   31.078272] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[   31.078377] pc : xilinx_dpdma_chan_queue_transfer+0x274/0x5e0[   31.078473] lr : xilinx_dpdma_chan_queue_transfer+0x270/0x5e0[   31.078550] sp : ffffffc083bb2e10[   31.078590] x29: ffffffc083bb2e10 x28: 0000000000000000 x27: ffffff880165a168[   31.078754] x26: ffffff880164e920 x25: ffffff880164eab8 x24: ffffff880164d480[   31.078920] x23: ffffff880165a148 x22: ffffff880164e988 x21: 0000000000000000[   31.079132] x20: ffffffc082aa3000 x19: ffffff880164e880 x18: 0000000000000000[   31.079295] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000[   31.079453] x14: 0000000000000000 x13: ffffff8802263dc0 x12: 0000000000000001[   31.079613] x11: 0001ffc083bb2e34 x10: 0001ff880164e98f x9 : 0001ffc082aa3def[   31.079824] x8 : 0001ffc082aa3dec x7 : 0000000000000000 x6 : 0000000000000516[   31.079982] x5 : ffffffc7f8d43000 x4 : ffffff88003c9c40 x3 : ffffffffffffffff[   31.080147] x2 : ffffffc7f8d43000 x1 : 00000000000000c0 x0 : 0000000000000000[   31.080307] Call trace:[   31.080340]  xilinx_dpdma_chan_queue_transfer+0x274/0x5e0[   31.080518]  xilinx_dpdma_issue_pending+0x11c/0x120[   31.080595]  zynqmp_disp_layer_update+0x180/0x3ac[   31.080712]  zynqmp_dpsub_plane_atomic_update+0x11c/0x21c[   31.080825]  drm_atomic_helper_commit_planes+0x20c/0x684[   31.080951]  drm_atomic_helper_commit_tail+0x5c/0xb0[   31.081139]  commit_tail+0x234/0x294[   31.081246]  drm_atomic_helper_commit+0x1f8/0x210[   31.081363]  drm_atomic_commit+0x100/0x140[   31.081477]  drm_client_modeset_commit_atomic+0x318/0x384[   31.081634]  drm_client_modeset_commit_locked+0x8c/0x24c[   31.081725]  drm_client_modeset_commit+0x34/0x5c[   31.081812]  __drm_fb_helper_restore_fbdev_mode_unlocked+0x104/0x168[   31.081899]  drm_fb_helper_set_par+0x50/0x70[   31.081971]  fbcon_init+0x538/0xc48[   31.082047]  visual_init+0x16c/0x23c[   31.082207]  do_bind_con_driver.isra.0+0x2d0/0x634[   31.082320]  do_take_over_console+0x24c/0x33c[   31.082429]  do_fbcon_takeover+0xbc/0x1b0[   31.082503]  fbcon_fb_registered+0x2d0/0x34c[   31.082663]  register_framebuffer+0x27c/0x38c[   31.082767]  __drm_fb_helper_initial_config_and_unlock+0x5c0/0x91c[   31.082939]  drm_fb_helper_initial_config+0x50/0x74[   31.083012]  drm_fbdev_dma_client_hotplug+0xb8/0x108[   31.083115]  drm_client_register+0xa0/0xf4[   31.083195]  drm_fbdev_dma_setup+0xb0/0x1cc[   31.083293]  zynqmp_dpsub_drm_init+0x45c/0x4e0[   31.083431]  zynqmp_dpsub_probe+0x444/0x5e0[   31.083616]  platform_probe+0x8c/0x13c[   31.083713]  really_probe+0x258/0x59c[   31.083793]  __driver_probe_device+0xc4/0x224[   31.083878]  driver_probe_device+0x70/0x1c0[   31.083961]  __device_attach_driver+0x108/0x1e0[   31.084052]  bus_for_each_drv+0x9c/0x100[   31.084125]  __device_attach+0x100/0x298[   31.084207]  device_initial_probe+0x14/0x20[   31.084292]  bus_probe_device+0xd8/0xdc[   31.084368]  deferred_probe_work_func+0x11c/0x180[   31.084451]  process_one_work+0x3ac/0x988[   31.084643]  worker_thread+0x398/0x694[   31.084752]  kthread+0x1bc/0x1c0[   31.084848]  ret_from_fork+0x10/0x20[   31.084932] irq event stamp: 64549[   31.084970] hardirqs last  enabled at (64548): [&lt;ffffffc081adf35c&gt;] _raw_spin_unlock_irqrestore+0x80/0x90[   31.085157]---truncated---(CVE-2024-35990)In the Linux kernel, the following vulnerability has been resolved:netfilter: nfnetlink_queue: acquire rcu_read_lock() in instance_destroy_rcu()syzbot reported that nf_reinject() could be called without rcu_read_lock() :WARNING: suspicious RCU usage6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Not taintednet/netfilter/nfnetlink_queue.c:263 suspicious rcu_dereference_check() usage!other info that might help us debug this:rcu_scheduler_active = 2, debug_locks = 12 locks held by syz-executor.4/13427:  #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:329 [inline]  #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_do_batch kernel/rcu/tree.c:2190 [inline]  #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_core+0xa86/0x1830 kernel/rcu/tree.c:2471  #1: ffff88801ca92958 (&amp;inst-&gt;lock){+.-.}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]  #1: ffff88801ca92958 (&amp;inst-&gt;lock){+.-.}-{2:2}, at: nfqnl_flush net/netfilter/nfnetlink_queue.c:405 [inline]  #1: ffff88801ca92958 (&amp;inst-&gt;lock){+.-.}-{2:2}, at: instance_destroy_rcu+0x30/0x220 net/netfilter/nfnetlink_queue.c:172stack backtrace:CPU: 0 PID: 13427 Comm: syz-executor.4 Not tainted 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024Call Trace: &lt;IRQ&gt;  __dump_stack lib/dump_stack.c:88 [inline]  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114  lockdep_rcu_suspicious+0x221/0x340 kernel/locking/lockdep.c:6712  nf_reinject net/netfilter/nfnetlink_queue.c:323 [inline]  nfqnl_reinject+0x6ec/0x1120 net/netfilter/nfnetlink_queue.c:397  nfqnl_flush net/netfilter/nfnetlink_queue.c:410 [inline]  instance_destroy_rcu+0x1ae/0x220 net/netfilter/nfnetlink_queue.c:172  rcu_do_batch kernel/rcu/tree.c:2196 [inline]  rcu_core+0xafd/0x1830 kernel/rcu/tree.c:2471  handle_softirqs+0x2d6/0x990 kernel/softirq.c:554  __do_softirq kernel/softirq.c:588 [inline]  invoke_softirq kernel/softirq.c:428 [inline]  __irq_exit_rcu+0xf4/0x1c0 kernel/softirq.c:637  irq_exit_rcu+0x9/0x30 kernel/softirq.c:649  instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [inline]  sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043 &lt;/IRQ&gt; &lt;TASK&gt;(CVE-2024-36286)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:soundwire: cadence: fix invalid PDI offsetFor some reason, we add an offset to the PDI, presumably to skip thePDI0 and PDI1 which are reserved for BPT.This code is however completely wrong and leads to an out-of-boundsaccess. We were just lucky so far since we used only a couple of PDIsand remained within the PDI array bounds.A Fixes: tag is not provided since there are no known platforms wherethe out-of-bounds would be accessed, and the initial code had problemsas well.A follow-up patch completely removes this useless offset.(CVE-2024-38635)In the Linux kernel, the following vulnerability has been resolved:riscv: prevent pt_regs corruption for secondary idle threadsTop of the kernel thread stack should be reserved for pt_regs. Howeverthis is not the case for the idle threads of the secondary boot harts.Their stacks overlap with their pt_regs, so both may get corrupted.Similar issue has been fixed for the primary hart, see c7cdd96eca28(&#34;riscv: prevent stack corruption by reserving task_pt_regs(p) early&#34;).However that fix was not propagated to the secondary harts. The problemhas been noticed in some CPU hotplug tests with V enabled. The functionsmp_callin stored several registers on stack, corrupting top of pt_regsstructure including status field. As a result, kernel attempted to saveor restore inexistent V context.(CVE-2024-38667)In the Linux kernel, the following vulnerability has been resolved:nvmet: fix a possible leak when destroy a ctrl during qp establishmentIn nvmet_sq_destroy we capture sq-&gt;ctrl early and if it is non-NULL weknow that a ctrl was allocated (in the admin connect request handler)and we need to release pending AERs, clear ctrl-&gt;sqs and sq-&gt;ctrl(for nvme-loop primarily), and drop the final reference on the ctrl.However, a small window is possible where nvmet_sq_destroy starts (asa result of the client giving up and disconnecting) concurrently withthe nvme admin connect cmd (which may be in an early stage). But *before*kill_and_confirm of sq-&gt;ref (i.e. the admin connect managed to get an sqlive reference). In this case, sq-&gt;ctrl was allocated however after it wascaptured in a local variable in nvmet_sq_destroy.This prevented the final reference drop on the ctrl.Solve this by re-capturing the sq-&gt;ctrl after all inflight request hascompleted, where for sure sq-&gt;ctrl reference is final, and move forwardbased on that.This issue was observed in an environment with many hosts connectingmultiple ctrls simoutanuosly, creating a delay in allocating a ctrlleading up to this race window.(CVE-2024-42152)In the Linux kernel, the following vulnerability has been resolved:dev/parport: fix the array out-of-bounds riskFixed array out-of-bounds issues caused by sprintfby replacing it with snprintf for safer data copying,ensuring the destination buffer is not overflowed.Below is the stack trace I encountered during the actual issue:[ 66.575408s] [pid:5118,cpu4,QThread,4]Kernel panic - not syncing: stack-protector:Kernel stack is corrupted in: do_hardware_base_addr+0xcc/0xd0 [parport][ 66.575408s] [pid:5118,cpu4,QThread,5]CPU: 4 PID: 5118 Comm:QThread Tainted: G S W O 5.10.97-arm64-desktop #7100.57021.2[ 66.575439s] [pid:5118,cpu4,QThread,6]TGID: 5087 Comm: EFileApp[ 66.575439s] [pid:5118,cpu4,QThread,7]Hardware name: HUAWEI HUAWEI QingYunPGUX-W515x-B081/SP1PANGUXM, BIOS 1.00.07 04/29/2024[ 66.575439s] [pid:5118,cpu4,QThread,8]Call trace:[ 66.575469s] [pid:5118,cpu4,QThread,9] dump_backtrace+0x0/0x1c0[ 66.575469s] [pid:5118,cpu4,QThread,0] show_stack+0x14/0x20[ 66.575469s] [pid:5118,cpu4,QThread,1] dump_stack+0xd4/0x10c[ 66.575500s] [pid:5118,cpu4,QThread,2] panic+0x1d8/0x3bc[ 66.575500s] [pid:5118,cpu4,QThread,3] __stack_chk_fail+0x2c/0x38[ 66.575500s] [pid:5118,cpu4,QThread,4] do_hardware_base_addr+0xcc/0xd0 [parport](CVE-2024-42301)In the Linux kernel, the following vulnerability has been resolved:exfat: fix potential deadlock on __exfat_get_dentry_setWhen accessing a file with more entries than ES_MAX_ENTRY_NUM, the bh-arrayis allocated in __exfat_get_entry_set. The problem is that the bh-array isallocated with GFP_KERNEL. It does not make sense. In the following cases,a deadlock for sbi-&gt;s_lock between the two processes may occur.       CPU0                CPU1       ----                ----  kswapd   balance_pgdat    lock(fs_reclaim)                      exfat_iterate                       lock(&amp;sbi-&gt;s_lock)                       exfat_readdir                        exfat_get_uniname_from_ext_entry                         exfat_get_dentry_set                          __exfat_get_dentry_set                           kmalloc_array                            ...                            lock(fs_reclaim)    ...    evict     exfat_evict_inode      lock(&amp;sbi-&gt;s_lock)To fix this, let&#39;s allocate bh-array with GFP_NOFS.(CVE-2024-42315)In the Linux kernel, the following vulnerability has been resolved:wifi: virt_wifi: avoid reporting connection success with wrong SSIDWhen user issues a connection with a different SSID than the onevirt_wifi has advertised, the __cfg80211_connect_result() willtrigger the warning: WARN_ON(bss_not_found).The issue is because the connection code in virt_wifi does notcheck the SSID from user space (it only checks the BSSID), andvirt_wifi will call cfg80211_connect_result() with WLAN_STATUS_SUCCESSeven if the SSID is different from the one virt_wifi has advertised.Eventually cfg80211 won&#39;t be able to find the cfg80211_bss and generatethe warning.Fixed it by checking the SSID (from user space) in the connection code.(CVE-2024-43841)In the Linux kernel, the following vulnerability has been resolved:jfs: Fix array-index-out-of-bounds in diFree(CVE-2024-43858)In the Linux kernel, the following vulnerability has been resolved:drm/nouveau: prime: fix refcount underflowCalling nouveau_bo_ref() on a nouveau_bo without initializing it (andhence the backing ttm_bo) leads to a refcount underflow.Instead of calling nouveau_bo_ref() in the unwind path ofdrm_gem_object_init(), clean things up manually.(cherry picked from commit 1b93f3e89d03cfc576636e195466a0d728ad8de5)(CVE-2024-43867)In the Linux kernel, the following vulnerability has been resolved:devres: Fix memory leakage caused by driver API devm_free_percpu()It will cause memory leakage when use driver API devm_free_percpu()to free memory allocated by devm_alloc_percpu(), fixed by usingdevres_release() instead of devres_destroy() within devm_free_percpu().(CVE-2024-43871)In the Linux kernel, the following vulnerability has been resolved:drm/client: fix null pointer dereference in drm_client_modeset_probeIn drm_client_modeset_probe(), the return value of drm_mode_duplicate() isassigned to modeset-&gt;mode, which will lead to a possible NULL pointerdereference on failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2024-43894)In the Linux kernel, the following vulnerability has been resolved:mptcp: pm: only decrement add_addr_accepted for MPJ reqAdding the following warning ...  WARN_ON_ONCE(msk-&gt;pm.add_addr_accepted == 0)... before decrementing the add_addr_accepted counter helped to find abug when running the &#34;remove single subflow&#34; subtest from themptcp_join.sh selftest.Removing a &#39;subflow&#39; endpoint will first trigger a RM_ADDR, then thesubflow closure. Before this patch, and upon the reception of theRM_ADDR, the other peer will then try to decrement thisadd_addr_accepted. That&#39;s not correct because the attached subflows havenot been created upon the reception of an ADD_ADDR.A way to solve that is to decrement the counter only if the attachedsubflow was an MP_JOIN to a remote id that was not 0, and initiated bythe host receiving the RM_ADDR.(CVE-2024-45009)In the Linux kernel, the following vulnerability has been resolved:usb: dwc3: core: Prevent USB core invalid event buffer address accessThis commit addresses an issue where the USB core could access aninvalid event buffer address during runtime suspend, potentially causingSMMU faults and other memory issues in Exynos platforms. The problemarises from the following sequence.        1. In dwc3_gadget_suspend, there is a chance of a timeout when        moving the USB core to the halt state after clearing the        run/stop bit by software.        2. In dwc3_core_exit, the event buffer is cleared regardless of        the USB core&#39;s status, which may lead to an SMMU faults and        other memory issues. if the USB core tries to access the event        buffer address.To prevent this hardware quirk on Exynos platforms, this commit ensuresthat the event buffer address is not cleared by software  when the USBcore is active during runtime suspend by checking its status beforeclearing the buffer address.(CVE-2024-46675)In the Linux kernel, the following vulnerability has been resolved:soc: qcom: cmd-db: Map shared memory as WC, not WBLinux does not write into cmd-db region. This region of memory is writeprotected by XPU. XPU may sometime falsely detect clean cache evictionas &#34;write&#34; into the write protected region leading to secure interruptwhich causes an endless loop somewhere in Trust Zone.The only reason it is working right now is because Qualcomm Hypervisormaps the same region as Non-Cacheable memory in Stage 2 translationtables. The issue manifests if we want to use another hypervisor (likeXen or KVM), which does not know anything about those specific mappings.Changing the mapping of cmd-db memory from MEMREMAP_WB to MEMREMAP_WT/WCremoves dependency on correct mappings in Stage 2 tables. This patchfixes the issue by updating the mapping to MEMREMAP_WC.I tested this on SA8155P with Xen.(CVE-2024-46689)In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: fix mc_data out-of-bounds read warningClear warning that read mc_data[i-1] may out-of-bounds.(CVE-2024-46722)In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix out-of-bounds read of df_v1_7_channel_numberCheck the fb_channel_number range to avoid the array out-of-boundsread error(CVE-2024-46724)In the Linux kernel, the following vulnerability has been resolved:hwmon: (nct6775-core) 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-46757)In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: added NULL check at start of dc_validate_stream[Why]prevent invalid memory access[How]check if dc and stream are NULL(CVE-2024-46802)In the Linux kernel, the following vulnerability has been resolved:KVM: x86: Acquire kvm-&gt;srcu when handling KVM_SET_VCPU_EVENTSGrab kvm-&gt;srcu when processing KVM_SET_VCPU_EVENTS, as KVM will forciblyleave nested VMX/SVM if SMM mode is being toggled, and leaving nested VMXreads guest memory.Note, kvm_vcpu_ioctl_x86_set_vcpu_events() can also be called from KVM_RUNvia sync_regs(), which already holds SRCU.  I.e. trying to precisely usekvm_vcpu_srcu_read_lock() around the problematic SMM code would causeproblems.  Acquiring SRCU isn&#39;t all that expensive, so for simplicity,grab it unconditionally for KVM_SET_VCPU_EVENTS. ============================= WARNING: suspicious RCU usage 6.10.0-rc7-332d2c1d713e-next-vm #552 Not tainted ----------------------------- include/linux/kvm_host.h:1027 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by repro/1071:  #0: ffff88811e424430 (&amp;vcpu-&gt;mutex){+.+.}-{3:3}, at: kvm_vcpu_ioctl+0x7d/0x970 [kvm] stack backtrace: CPU: 15 PID: 1071 Comm: repro Not tainted 6.10.0-rc7-332d2c1d713e-next-vm #552 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace:  &lt;TASK&gt;  dump_stack_lvl+0x7f/0x90  lockdep_rcu_suspicious+0x13f/0x1a0  kvm_vcpu_gfn_to_memslot+0x168/0x190 [kvm]  kvm_vcpu_read_guest+0x3e/0x90 [kvm]  nested_vmx_load_msr+0x6b/0x1d0 [kvm_intel]  load_vmcs12_host_state+0x432/0xb40 [kvm_intel]  vmx_leave_nested+0x30/0x40 [kvm_intel]  kvm_vcpu_ioctl_x86_set_vcpu_events+0x15d/0x2b0 [kvm]  kvm_arch_vcpu_ioctl+0x1107/0x1750 [kvm]  ? mark_held_locks+0x49/0x70  ? kvm_vcpu_ioctl+0x7d/0x970 [kvm]  ? kvm_vcpu_ioctl+0x497/0x970 [kvm]  kvm_vcpu_ioctl+0x497/0x970 [kvm]  ? lock_acquire+0xba/0x2d0  ? find_held_lock+0x2b/0x80  ? do_user_addr_fault+0x40c/0x6f0  ? lock_release+0xb7/0x270  __x64_sys_ioctl+0x82/0xb0  do_syscall_64+0x6c/0x170  entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7ff11eb1b539  &lt;/TASK&gt;(CVE-2024-46830)In the Linux kernel, the following vulnerability has been resolved:spi: nxp-fspi: fix the KASAN report out-of-bounds bugChange the memcpy length to fix the out-of-bounds issue when writing thedata that is not 4 byte aligned to TX FIFO.To reproduce the issue, write 3 bytes data to NOR chip.dd if=3b of=/dev/mtd0[   36.926103] ==================================================================[   36.933409] BUG: KASAN: slab-out-of-bounds in nxp_fspi_exec_op+0x26ec/0x2838[   36.940514] Read of size 4 at addr ffff00081037c2a0 by task dd/455[   36.946721][   36.948235] CPU: 3 UID: 0 PID: 455 Comm: dd Not tainted 6.11.0-rc5-gc7b0e37c8434 #1070[   36.956185] Hardware name: Freescale i.MX8QM MEK (DT)[   36.961260] Call trace:[   36.963723]  dump_backtrace+0x90/0xe8[   36.967414]  show_stack+0x18/0x24[   36.970749]  dump_stack_lvl+0x78/0x90[   36.974451]  print_report+0x114/0x5cc[   36.978151]  kasan_report+0xa4/0xf0[   36.981670]  __asan_report_load_n_noabort+0x1c/0x28[   36.986587]  nxp_fspi_exec_op+0x26ec/0x2838[   36.990800]  spi_mem_exec_op+0x8ec/0xd30[   36.994762]  spi_mem_no_dirmap_read+0x190/0x1e0[   36.999323]  spi_mem_dirmap_write+0x238/0x32c[   37.003710]  spi_nor_write_data+0x220/0x374[   37.007932]  spi_nor_write+0x110/0x2e8[   37.011711]  mtd_write_oob_std+0x154/0x1f0[   37.015838]  mtd_write_oob+0x104/0x1d0[   37.019617]  mtd_write+0xb8/0x12c[   37.022953]  mtdchar_write+0x224/0x47c[   37.026732]  vfs_write+0x1e4/0x8c8[   37.030163]  ksys_write+0xec/0x1d0[   37.033586]  __arm64_sys_write+0x6c/0x9c[   37.037539]  invoke_syscall+0x6c/0x258[   37.041327]  el0_svc_common.constprop.0+0x160/0x22c[   37.046244]  do_el0_svc+0x44/0x5c[   37.049589]  el0_svc+0x38/0x78[   37.052681]  el0t_64_sync_handler+0x13c/0x158[   37.057077]  el0t_64_sync+0x190/0x194[   37.060775][   37.062274] Allocated by task 455:[   37.065701]  kasan_save_stack+0x2c/0x54[   37.069570]  kasan_save_track+0x20/0x3c[   37.073438]  kasan_save_alloc_info+0x40/0x54[   37.077736]  __kasan_kmalloc+0xa0/0xb8[   37.081515]  __kmalloc_noprof+0x158/0x2f8[   37.085563]  mtd_kmalloc_up_to+0x120/0x154[   37.089690]  mtdchar_write+0x130/0x47c[   37.093469]  vfs_write+0x1e4/0x8c8[   37.096901]  ksys_write+0xec/0x1d0[   37.100332]  __arm64_sys_write+0x6c/0x9c[   37.104287]  invoke_syscall+0x6c/0x258[   37.108064]  el0_svc_common.constprop.0+0x160/0x22c[   37.112972]  do_el0_svc+0x44/0x5c[   37.116319]  el0_svc+0x38/0x78[   37.119401]  el0t_64_sync_handler+0x13c/0x158[   37.123788]  el0t_64_sync+0x190/0x194[   37.127474][   37.128977] The buggy address belongs to the object at ffff00081037c2a0[   37.128977]  which belongs to the cache kmalloc-8 of size 8[   37.141177] The buggy address is located 0 bytes inside of[   37.141177]  allocated 3-byte region [ffff00081037c2a0, ffff00081037c2a3)[   37.153465][   37.154971] The buggy address belongs to the physical page:[   37.160559] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x89037c[   37.168596] flags: 0xbfffe0000000000(node=0|zone=2|lastcpupid=0x1ffff)[   37.175149] page_type: 0xfdffffff(slab)[   37.179021] raw: 0bfffe0000000000 ffff000800002500 dead000000000122 0000000000000000[   37.186788] raw: 0000000000000000 0000000080800080 00000001fdffffff 0000000000000000[   37.194553] page dumped because: kasan: bad access detected[   37.200144][   37.201647] Memory state around the buggy address:[   37.206460]  ffff00081037c180: fa fc fc fc fa fc fc fc fa fc fc fc fa fc fc fc[   37.213701]  ffff00081037c200: fa fc fc fc 05 fc fc fc 03 fc fc fc 02 fc fc fc[   37.220946] &gt;ffff00081037c280: 06 fc fc fc 03 fc fc fc fc fc fc fc fc fc fc fc[   37.228186]                                ^[   37.232473]  ffff00081037c300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc[   37.239718]  ffff00081037c380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc[   37.246962] ==============================================================---truncated---(CVE-2024-46853)In the Linux kernel, the following vulnerability has been resolved:PCI: keystone: Add workaround for Errata #i2037 (AM65x SR 1.0)Errata #i2037 in AM65x/DRA80xM Processors Silicon Revision 1.0(SPRZ452D_July 2018_Revised December 2019 [1]) mentions when aninbound PCIe TLP spans more than two internal AXI 128-byte bursts,the bus may corrupt the packet payload and the corrupt data maycause associated applications or the processor to hang.The workaround for Errata #i2037 is to limit the maximum readrequest size and maximum payload size to 128 bytes. Add workaroundfor Errata #i2037 here.The errata and workaround is applicable only to AM65x SR 1.0 andlater versions of the silicon will have this fixed.[1] -&gt; https://www.ti.com/lit/er/sprz452i/sprz452i.pdf(CVE-2024-47667)In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix state management in error path of log writing functionAfter commit a694291a6211 (&#34;nilfs2: separate wait function fromnilfs_segctor_write&#34;) was applied, the log writing functionnilfs_segctor_do_construct() was able to issue I/O requests continuouslyeven if user data blocks were split into multiple logs across segments,but two potential flaws were introduced in its error handling.First, if nilfs_segctor_begin_construction() fails while creating thesecond or subsequent logs, the log writing function returns withoutcalling nilfs_segctor_abort_construction(), so the writeback flag set onpages/folios will remain uncleared.  This causes page cache operations tohang waiting for the writeback flag.  For example,truncate_inode_pages_final(), which is called via nilfs_evict_inode() whenan inode is evicted from memory, will hang.Second, the NILFS_I_COLLECTED flag set on normal inodes remain uncleared. As a result, if the next log write involves checkpoint creation, that&#39;sfine, but if a partial log write is performed that does not, inodes withNILFS_I_COLLECTED set are erroneously removed from the &#34;sc_dirty_files&#34;list, and their data and b-tree blocks may not be written to the device,corrupting the block mapping.Fix these issues by uniformly calling nilfs_segctor_abort_construction()on failure of each step in the loop in nilfs_segctor_do_construct(),having it clean up logs and segment usages according to progress, andcorrecting the conditions for calling nilfs_redirty_inodes() to ensurethat the NILFS_I_COLLECTED flag is cleared.(CVE-2024-47669)In the Linux kernel, the following vulnerability has been resolved:  tcp: check skb is non-NULL in tcp_rto_delta_us()  We have some machines running stock Ubuntu 20.04.6 which is their 5.4.0-174-generic kernel that are running ceph and recently hit a null ptr dereference in tcp_rearm_rto(). Initially hitting it from the TLP path, but then later we also saw it getting hit from the RACK case as well. Here are examples of the oops messages we saw in each of those cases:  Jul 26 15:05:02 rx [11061395.780353] BUG: kernel NULL pointer dereference, address: 0000000000000020 Jul 26 15:05:02 rx [11061395.787572] #PF: supervisor read access in kernel mode Jul 26 15:05:02 rx [11061395.792971] #PF: error_code(0x0000) - not-present page Jul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0 Jul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTI Jul 26 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Tainted: G W 5.4.0-174-generic #193-Ubuntu Jul 26 15:05:02 rx [11061395.814996] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023 Jul 26 15:05:02 rx [11061395.825952] RIP: 0010:tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.830656] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 &lt;48&gt; 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3 Jul 26 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246 Jul 26 15:05:02 rx [11061395.855149] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000 Jul 26 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60 Jul 26 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8 Jul 26 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900 Jul 26 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30 Jul 26 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000 Jul 26 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jul 26 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0 Jul 26 15:05:02 rx [11061395.913822] PKRU: 55555554 Jul 26 15:05:02 rx [11061395.916786] Call Trace: Jul 26 15:05:02 rx [11061395.919488] Jul 26 15:05:02 rx [11061395.921765] ? show_regs.cold+0x1a/0x1f Jul 26 15:05:02 rx [11061395.925859] ? __die+0x90/0xd9 Jul 26 15:05:02 rx [11061395.929169] ? no_context+0x196/0x380 Jul 26 15:05:02 rx [11061395.933088] ? ip6_protocol_deliver_rcu+0x4e0/0x4e0 Jul 26 15:05:02 rx [11061395.938216] ? ip6_sublist_rcv_finish+0x3d/0x50 Jul 26 15:05:02 rx [11061395.943000] ? __bad_area_nosemaphore+0x50/0x1a0 Jul 26 15:05:02 rx [11061395.947873] ? bad_area_nosemaphore+0x16/0x20 Jul 26 15:05:02 rx [11061395.952486] ? do_user_addr_fault+0x267/0x450 Jul 26 15:05:02 rx [11061395.957104] ? ipv6_list_rcv+0x112/0x140 Jul 26 15:05:02 rx [11061395.961279] ? __do_page_fault+0x58/0x90 Jul 26 15:05:02 rx [11061395.965458] ? do_page_fault+0x2c/0xe0 Jul 26 15:05:02 rx [11061395.969465] ? page_fault+0x34/0x40 Jul 26 15:05:02 rx [11061395.973217] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.977313] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.981408] tcp_send_loss_probe+0x10b/0x220 Jul 26 15:05:02 rx [11061395.985937] tcp_write_timer_handler+0x1b4/0x240 Jul 26 15:05:02 rx [11061395.990809] tcp_write_timer+0x9e/0xe0 Jul 26 15:05:02 rx [11061395.994814] ? tcp_write_timer_handler+0x240/0x240 Jul 26 15:05:02 rx [11061395.999866] call_timer_fn+0x32/0x130 Jul 26 15:05:02 rx [11061396.003782] __run_timers.part.0+0x180/0x280 Jul 26 15:05:02 rx [11061396.008309] ? recalibrate_cpu_khz+0x10/0x10 Jul 26 15:05:02 rx [11061396.012841] ? native_x2apic_icr_write+0x30/0x30 Jul 26 15:05:02 rx [11061396.017718] ? lapic_next_even ---truncated---(CVE-2024-47684)In the Linux kernel, the following vulnerability has been resolved:  netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put()  syzbot reported that nf_reject_ip6_tcphdr_put() was possibly sending garbage on the four reserved tcp bits (th-&gt;res1)  Use skb_put_zero() to clear the whole TCP header, as done in nf_reject_ip_tcphdr_put()  BUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255   nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255   nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344   nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48   expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]   nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288   nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161   nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]   nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626   nf_hook include/linux/netfilter.h:269 [inline]   NF_HOOK include/linux/netfilter.h:312 [inline]   ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310   __netif_receive_skb_one_core net/core/dev.c:5661 [inline]   __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775   process_backlog+0x4ad/0xa50 net/core/dev.c:6108   __napi_poll+0xe7/0x980 net/core/dev.c:6772   napi_poll net/core/dev.c:6841 [inline]   net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963   handle_softirqs+0x1ce/0x800 kernel/softirq.c:554   __do_softirq+0x14/0x1a kernel/softirq.c:588   do_softirq+0x9a/0x100 kernel/softirq.c:455   __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382   local_bh_enable include/linux/bottom_half.h:33 [inline]   rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline]   __dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450   dev_queue_xmit include/linux/netdevice.h:3105 [inline]   neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565   neigh_output include/net/neighbour.h:542 [inline]   ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141   __ip6_finish_output net/ipv6/ip6_output.c:215 [inline]   ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226   NF_HOOK_COND include/linux/netfilter.h:303 [inline]   ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247   dst_output include/net/dst.h:450 [inline]   NF_HOOK include/linux/netfilter.h:314 [inline]   ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366   inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135   __tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466   tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline]   tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143   tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333   __inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679   inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750   __sys_connect_file net/socket.c:2061 [inline]   __sys_connect+0x606/0x690 net/socket.c:2078   __do_sys_connect net/socket.c:2088 [inline]   __se_sys_connect net/socket.c:2085 [inline]   __x64_sys_connect+0x91/0xe0 net/socket.c:2085   x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43   do_syscall_x64 arch/x86/entry/common.c:52 [inline]   do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  Uninit was stored to memory at:   nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249   nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344   nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48   expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]   nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288   nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161   nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]   nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626   nf_hook include/linux/netfilter.h:269 [inline]   NF_HOOK include/linux/netfilter.h:312 [inline]   ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310   __netif_receive_skb_one_core ---truncated---(CVE-2024-47685)In the Linux kernel, the following vulnerability has been resolved:  nfsd: return -EINVAL when namelen is 0  When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may result in namelen being 0, which will cause memdup_user() to return ZERO_SIZE_PTR. When we access the name.data that has been assigned the value of ZERO_SIZE_PTR in nfs4_client_to_reclaim(), null pointer dereference is triggered.  [ T1205] ================================================================== [ T1205] BUG: KASAN: null-ptr-deref in nfs4_client_to_reclaim+0xe9/0x260 [ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205 [ T1205] [ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406 [ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ T1205] Call Trace: [ T1205]  dump_stack+0x9a/0xd0 [ T1205]  ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205]  __kasan_report.cold+0x34/0x84 [ T1205]  ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205]  kasan_report+0x3a/0x50 [ T1205]  nfs4_client_to_reclaim+0xe9/0x260 [ T1205]  ? nfsd4_release_lockowner+0x410/0x410 [ T1205]  cld_pipe_downcall+0x5ca/0x760 [ T1205]  ? nfsd4_cld_tracking_exit+0x1d0/0x1d0 [ T1205]  ? down_write_killable_nested+0x170/0x170 [ T1205]  ? avc_policy_seqno+0x28/0x40 [ T1205]  ? selinux_file_permission+0x1b4/0x1e0 [ T1205]  rpc_pipe_write+0x84/0xb0 [ T1205]  vfs_write+0x143/0x520 [ T1205]  ksys_write+0xc9/0x170 [ T1205]  ? __ia32_sys_read+0x50/0x50 [ T1205]  ? ktime_get_coarse_real_ts64+0xfe/0x110 [ T1205]  ? ktime_get_coarse_real_ts64+0xa2/0x110 [ T1205]  do_syscall_64+0x33/0x40 [ T1205]  entry_SYSCALL_64_after_hwframe+0x67/0xd1 [ T1205] RIP: 0033:0x7fdbdb761bc7 [ T1205] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 &lt;48&gt; 3d 00 f0 ff ff 77 514 [ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7 [ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008 [ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001 [ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b [ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000 [ T1205] ==================================================================  Fix it by checking namelen.(CVE-2024-47692)In the Linux kernel, the following vulnerability has been resolved:  RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds  In the function init_conns(), after the create_con() and create_cm() for loop if something fails. In the cleanup for loop after the destroy tag, we access out of bound memory because cid is set to clt_path-&gt;s.con_num.  This commits resets the cid to clt_path-&gt;s.con_num - 1, to stay in bounds in the cleanup loop later.(CVE-2024-47695)In the Linux kernel, the following vulnerability has been resolved:  drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error  Ensure index in rtl2832_pid_filter does not exceed 31 to prevent out-of-bounds access.  dev-&gt;filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index &gt; 32 to index &gt;= 32 to resolve this issue.  [hverkuil: added fixes tag, rtl2830_pid_filter -&gt; rtl2832_pid_filter in logmsg](CVE-2024-47698)In the Linux kernel, the following vulnerability has been resolved:  can: bcm: Clear bo-&gt;bcm_proc_read after remove_proc_entry().  syzbot reported a warning in bcm_release(). [0]  The blamed change fixed another warning that is triggered when connect() is issued again for a socket whose connect()ed device has been unregistered.  However, if the socket is just close()d without the 2nd connect(), the remaining bo-&gt;bcm_proc_read triggers unnecessary remove_proc_entry() in bcm_release().  Let&#39;s clear bo-&gt;bcm_proc_read after remove_proc_entry() in bcm_notify().  [0] name &#39;4986&#39; WARNING: CPU: 0 PID: 5234 at fs/proc/generic.c:711 remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Modules linked in: CPU: 0 UID: 0 PID: 5234 Comm: syz-executor606 Not tainted 6.11.0-rc5-syzkaller-00178-g5517ae241919 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Code: ff eb 05 e8 cb 1e 5e ff 48 8b 5c 24 10 48 c7 c7 e0 f7 aa 8e e8 2a 38 8e 09 90 48 c7 c7 60 3a 1b 8c 48 89 de e8 da 42 20 ff 90 &lt;0f&gt; 0b 90 90 48 8b 44 24 18 48 c7 44 24 40 0e 36 e0 45 49 c7 04 07 RSP: 0018:ffffc9000345fa20 EFLAGS: 00010246 RAX: 2a2d0aee2eb64600 RBX: ffff888032f1f548 RCX: ffff888029431e00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000345fb08 R08: ffffffff8155b2f2 R09: 1ffff1101710519a R10: dffffc0000000000 R11: ffffed101710519b R12: ffff888011d38640 R13: 0000000000000004 R14: 0000000000000000 R15: dffffc0000000000 FS:  0000000000000000(0000) GS:ffff8880b8800000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcfb52722f0 CR3: 000000000e734000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace:  &lt;TASK&gt;  bcm_release+0x250/0x880 net/can/bcm.c:1578  __sock_release net/socket.c:659 [inline]  sock_close+0xbc/0x240 net/socket.c:1421  __fput+0x24a/0x8a0 fs/file_table.c:422  task_work_run+0x24f/0x310 kernel/task_work.c:228  exit_task_work include/linux/task_work.h:40 [inline]  do_exit+0xa2f/0x27f0 kernel/exit.c:882  do_group_exit+0x207/0x2c0 kernel/exit.c:1031  __do_sys_exit_group kernel/exit.c:1042 [inline]  __se_sys_exit_group kernel/exit.c:1040 [inline]  __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040  x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232  do_syscall_x64 arch/x86/entry/common.c:52 [inline]  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fcfb51ee969 Code: Unable to access opcode bytes at 0x7fcfb51ee93f. RSP: 002b:00007ffce0109ca8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fcfb51ee969 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 00007fcfb526f3b0 R08: ffffffffffffffb8 R09: 0000555500000000 R10: 0000555500000000 R11: 0000000000000246 R12: 00007fcfb526f3b0 R13: 0000000000000000 R14: 00007fcfb5271ee0 R15: 00007fcfb51bf160  &lt;/TASK&gt;(CVE-2024-47709)In the Linux kernel, the following vulnerability has been resolved:  sock_map: Add a cond_resched() in sock_hash_free()  Several syzbot soft lockup reports all have in common sock_hash_free()  If a map with a large number of buckets is destroyed, we need to yield the cpu when needed.(CVE-2024-47710)In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Add null check for set_output_gamma in dcn30_set_output_transfer_func  This commit adds a null check for the set_output_gamma function pointer in the  dcn30_set_output_transfer_func function. Previously, set_output_gamma was being checked for nullity at line 386, but then it was being dereferenced without any nullity check at line 401. This could potentially lead to a null pointer dereference error if set_output_gamma is indeed null.  To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a nullity check for set_output_gamma before the call to set_output_gamma at line 401. If set_output_gamma is null, we log an error message and do not call the function.  This fix prevents a potential null pointer dereference error.  drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:401 dcn30_set_output_transfer_func() error: we previously assumed &#39;mpc-&gt;funcs-&gt;set_output_gamma&#39; could be null (see line 386)  drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c     373 bool dcn30_set_output_transfer_func(struct dc *dc,     374                                 struct pipe_ctx *pipe_ctx,     375                                 const struct dc_stream_state *stream)     376 {     377         int mpcc_id = pipe_ctx-&gt;plane_res.hubp-&gt;inst;     378         struct mpc *mpc = pipe_ctx-&gt;stream_res.opp-&gt;ctx-&gt;dc-&gt;res_pool-&gt;mpc;     379         const struct pwl_params *params = NULL;     380         bool ret = false;     381     382         /* program OGAM or 3DLUT only for the top pipe*/     383         if (pipe_ctx-&gt;top_pipe == NULL) {     384                 /*program rmu shaper and 3dlut in MPC*/     385                 ret = dcn30_set_mpc_shaper_3dlut(pipe_ctx, stream);     386                 if (ret == false &amp;&amp; mpc-&gt;funcs-&gt;set_output_gamma) {                                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If this is NULL      387                         if (stream-&gt;out_transfer_func.type == TF_TYPE_HWPWL)     388                                 params = &amp;stream-&gt;out_transfer_func.pwl;     389                         else if (pipe_ctx-&gt;stream-&gt;out_transfer_func.type ==     390                                         TF_TYPE_DISTRIBUTED_POINTS &amp;&amp;     391                                         cm3_helper_translate_curve_to_hw_format(     392                                         &amp;stream-&gt;out_transfer_func,     393                                         &amp;mpc-&gt;blender_params, false))     394                                 params = &amp;mpc-&gt;blender_params;     395                          /* there are no ROM LUTs in OUTGAM */     396                         if (stream-&gt;out_transfer_func.type == TF_TYPE_PREDEFINED)     397                                 BREAK_TO_DEBUGGER();     398                 }     399         }     400 --&gt; 401         mpc-&gt;funcs-&gt;set_output_gamma(mpc, mpcc_id, params);                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Then it will crash      402         return ret;     403 }(CVE-2024-47720)In the Linux kernel, the following vulnerability has been resolved:  RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled  Fix missuse of spin_lock_irq()/spin_unlock_irq() when spin_lock_irqsave()/spin_lock_irqrestore() was hold.  This was discovered through the lock debugging, and the corresponding log is as follows:  raw_local_irq_restore() called with IRQs enabled WARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40 ... Call trace:  warn_bogus_irq_restore+0x30/0x40  _raw_spin_unlock_irqrestore+0x84/0xc8  add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2]  hns_roce_create_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2]  hns_roce_create_qp+0x98/0x160 [hns_roce_hw_v2]  create_qp+0x138/0x258  ib_create_qp_kernel+0x50/0xe8  create_mad_qp+0xa8/0x128  ib_mad_port_open+0x218/0x448  ib_mad_init_device+0x70/0x1f8  add_client_context+0xfc/0x220  enable_device_and_get+0xd0/0x140  ib_register_device.part.0+0xf4/0x1c8  ib_register_device+0x34/0x50  hns_roce_register_device+0x174/0x3d0 [hns_roce_hw_v2]  hns_roce_init+0xfc/0x2c0 [hns_roce_hw_v2]  __hns_roce_hw_v2_init_instance+0x7c/0x1d0 [hns_roce_hw_v2]  hns_roce_hw_v2_init_instance+0x9c/0x180 [hns_roce_hw_v2](CVE-2024-47735)In the Linux kernel, the following vulnerability has been resolved:  nfsd: call cache_put if xdr_reserve_space returns NULL  If not enough buffer space available, but idmap_lookup has triggered lookup_fn which calls cache_get and returns successfully. Then we missed to call cache_put here which pairs with cache_get.  Reviwed-by: Jeff Layton &lt;jlayton@kernel.org&gt;(CVE-2024-47737)In the Linux kernel, the following vulnerability has been resolved:  nilfs2: fix potential oob read in nilfs_btree_check_delete()  The function nilfs_btree_check_delete(), which checks whether degeneration to direct mapping occurs before deleting a b-tree entry, causes memory access outside the block buffer when retrieving the maximum key if the root node has no entries.  This does not usually happen because b-tree mappings with 0 child nodes are never created by mkfs.nilfs2 or nilfs2 itself.  However, it can happen if the b-tree root node read from a device is configured that way, so fix this potential issue by adding a check for that case.(CVE-2024-47757)In the Linux kernel, the following vulnerability has been resolved:  tracing/timerlat: Fix a race during cpuhp processing  There is another found exception that the &#34;timerlat/1&#34; thread was scheduled on CPU0, and lead to timer corruption finally:  ``` ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace:  &lt;TASK&gt;  ? __warn+0x7c/0x110  ? debug_print_object+0x7d/0xb0  ? report_bug+0xf1/0x1d0  ? prb_read_valid+0x17/0x20  ? handle_bug+0x3f/0x70  ? exc_invalid_op+0x13/0x60  ? asm_exc_invalid_op+0x16/0x20  ? debug_print_object+0x7d/0xb0  ? debug_print_object+0x7d/0xb0  ? __pfx_timerlat_irq+0x10/0x10  __debug_object_init+0x110/0x150  hrtimer_init+0x1d/0x60  timerlat_main+0xab/0x2d0  ? __pfx_timerlat_main+0x10/0x10  kthread+0xb7/0xe0  ? __pfx_kthread+0x10/0x10  ret_from_fork+0x2d/0x40  ? __pfx_kthread+0x10/0x10  ret_from_fork_asm+0x1a/0x30  &lt;/TASK&gt; ```  After tracing the scheduling event, it was discovered that the migration of the &#34;timerlat/1&#34; thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU:  T1                       | T2 [CPUHP_ONLINE]           | cpu_device_down() osnoise_hotplug_workfn() |                          |     cpus_write_lock()                          |     takedown_cpu(1)                          |     cpus_write_unlock() [CPUHP_OFFLINE]          |     cpus_read_lock()     |     start_kthread(1)     |     cpus_read_unlock()   |  To fix this, skip online processing if the CPU is already offline.(CVE-2024-49866)In the Linux kernel, the following vulnerability has been resolved:  btrfs: wait for fixup workers before stopping cleaner kthread during umount  During unmount, at close_ctree(), we have the following steps in this order:  1) Park the cleaner kthread - this doesn&#39;t destroy the kthread, it basically    halts its execution (wake ups against it work but do nothing);  2) We stop the cleaner kthread - this results in freeing the respective    struct task_struct;  3) We call btrfs_stop_all_workers() which waits for any jobs running in all    the work queues and then free the work queues.  Syzbot reported a case where a fixup worker resulted in a crash when doing a delayed iput on its inode while attempting to wake up the cleaner at btrfs_add_delayed_iput(), because the task_struct of the cleaner kthread was already freed. This can happen during unmount because we don&#39;t wait for any fixup workers still running before we call kthread_stop() against the cleaner kthread, which stops and free all its resources.  Fix this by waiting for any fixup workers at close_ctree() before we call kthread_stop() against the cleaner and run pending delayed iputs.  The stack traces reported by syzbot were the following:    BUG: KASAN: slab-use-after-free in __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065   Read of size 8 at addr ffff8880272a8a18 by task kworker/u8:3/52    CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.12.0-rc1-syzkaller #0   Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024   Workqueue: btrfs-fixup btrfs_work_helper   Call Trace:    &lt;TASK&gt;    __dump_stack lib/dump_stack.c:94 [inline]    dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120    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    __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065    lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825    __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]    _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162    class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline]    try_to_wake_up+0xb0/0x1480 kernel/sched/core.c:4154    btrfs_writepage_fixup_worker+0xc16/0xdf0 fs/btrfs/inode.c:2842    btrfs_work_helper+0x390/0xc50 fs/btrfs/async-thread.c:314    process_one_work kernel/workqueue.c:3229 [inline]    process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310    worker_thread+0x870/0xd30 kernel/workqueue.c:3391    kthread+0x2f0/0x390 kernel/kthread.c:389    ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147    ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244    &lt;/TASK&gt;    Allocated by task 2:    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:319 [inline]    __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345    kasan_slab_alloc include/linux/kasan.h:247 [inline]    slab_post_alloc_hook mm/slub.c:4086 [inline]    slab_alloc_node mm/slub.c:4135 [inline]    kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4187    alloc_task_struct_node kernel/fork.c:180 [inline]    dup_task_struct+0x57/0x8c0 kernel/fork.c:1107    copy_process+0x5d1/0x3d50 kernel/fork.c:2206    kernel_clone+0x223/0x880 kernel/fork.c:2787    kernel_thread+0x1bc/0x240 kernel/fork.c:2849    create_kthread kernel/kthread.c:412 [inline]    kthreadd+0x60d/0x810 kernel/kthread.c:765    ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147    ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244    Freed by task 61:    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 mm/kasan/common.c:247 [inline]    __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264    kasan_slab_free include/linux/kasan.h:230 [inline]    slab_free_h ---truncated---(CVE-2024-49867)In the Linux kernel, the following vulnerability has been resolved:  btrfs: fix a NULL pointer dereference when failed to start a new trasacntion  [BUG] Syzbot reported a NULL pointer dereference with the following crash:    FAULT_INJECTION: forcing a failure.    start_transaction+0x830/0x1670 fs/btrfs/transaction.c:676    prepare_to_relocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642    relocate_block_group+0x169/0xd20 fs/btrfs/relocation.c:3678   ...   BTRFS info (device loop0): balance: ended with status: -12   Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI   KASAN: null-ptr-deref in range [0x0000000000000660-0x0000000000000667]   RIP: 0010:btrfs_update_reloc_root+0x362/0xa80 fs/btrfs/relocation.c:926   Call Trace:    &lt;TASK&gt;    commit_fs_roots+0x2ee/0x720 fs/btrfs/transaction.c:1496    btrfs_commit_transaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430    del_balance_item fs/btrfs/volumes.c:3678 [inline]    reset_balance_state+0x25e/0x3c0 fs/btrfs/volumes.c:3742    btrfs_balance+0xead/0x10c0 fs/btrfs/volumes.c:4574    btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673    vfs_ioctl fs/ioctl.c:51 [inline]    __do_sys_ioctl fs/ioctl.c:907 [inline]    __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893    do_syscall_x64 arch/x86/entry/common.c:52 [inline]    do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83    entry_SYSCALL_64_after_hwframe+0x77/0x7f  [CAUSE] The allocation failure happens at the start_transaction() inside prepare_to_relocate(), and during the error handling we call unset_reloc_control(), which makes fs_info-&gt;balance_ctl to be NULL.  Then we continue the error path cleanup in btrfs_balance() by calling reset_balance_state() which will call del_balance_item() to fully delete the balance item in the root tree.  However during the small window between set_reloc_contrl() and unset_reloc_control(), we can have a subvolume tree update and created a reloc_root for that subvolume.  Then we go into the final btrfs_commit_transaction() of del_balance_item(), and into btrfs_update_reloc_root() inside commit_fs_roots().  That function checks if fs_info-&gt;reloc_ctl is in the merge_reloc_tree stage, but since fs_info-&gt;reloc_ctl is NULL, it results a NULL pointer dereference.  [FIX] Just add extra check on fs_info-&gt;reloc_ctl inside btrfs_update_reloc_root(), before checking fs_info-&gt;reloc_ctl-&gt;merge_reloc_tree.  That DEAD_RELOC_TREE handling is to prevent further modification to the reloc tree during merge stage, but since there is no reloc_ctl at all, we do not need to bother that.(CVE-2024-49868)In the Linux kernel, the following vulnerability has been resolved:  nfsd: map the EBADMSG to nfserr_io to avoid warning  Ext4 will throw -EBADMSG through ext4_readdir when a checksum error occurs, resulting in the following WARNING.  Fix it by mapping EBADMSG to nfserr_io.  nfsd_buffered_readdir  iterate_dir // -EBADMSG -74   ext4_readdir // .iterate_shared    ext4_dx_readdir     ext4_htree_fill_tree      htree_dirblock_to_tree       ext4_read_dirblock        __ext4_read_dirblock         ext4_dirblock_csum_verify          warn_no_space_for_csum           __warn_no_space_for_csum         return ERR_PTR(-EFSBADCRC) // -EBADMSG -74  nfserrno // WARNING  [  161.115610] ------------[ cut here ]------------ [  161.116465] nfsd: non-standard errno: -74 [  161.117315] WARNING: CPU: 1 PID: 780 at fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0 [  161.118596] Modules linked in: [  161.119243] CPU: 1 PID: 780 Comm: nfsd Not tainted 5.10.0-00014-g79679361fd5d #138 [  161.120684] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qe mu.org 04/01/2014 [  161.123601] RIP: 0010:nfserrno+0x9d/0xd0 [  161.124676] Code: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6  05 ce 2b 61 03 01 e8 99 20 d8 00 &lt;0f&gt; 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33 [  161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286 [  161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [  161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 RDI: fffff520001c5f2a [  161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827 [  161.132664] R10: ffffed103ee18304 R11: 0000000000000001 R12: 0000000000000021 [  161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8 [  161.135244] FS:  0000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000 [  161.136695] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [  161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0 [  161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [  161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [  161.141519] PKRU: 55555554 [  161.142076] Call Trace: [  161.142575]  ? __warn+0x9b/0x140 [  161.143229]  ? nfserrno+0x9d/0xd0 [  161.143872]  ? report_bug+0x125/0x150 [  161.144595]  ? handle_bug+0x41/0x90 [  161.145284]  ? exc_invalid_op+0x14/0x70 [  161.146009]  ? asm_exc_invalid_op+0x12/0x20 [  161.146816]  ? nfserrno+0x9d/0xd0 [  161.147487]  nfsd_buffered_readdir+0x28b/0x2b0 [  161.148333]  ? nfsd4_encode_dirent_fattr+0x380/0x380 [  161.149258]  ? nfsd_buffered_filldir+0xf0/0xf0 [  161.150093]  ? wait_for_concurrent_writes+0x170/0x170 [  161.151004]  ? generic_file_llseek_size+0x48/0x160 [  161.151895]  nfsd_readdir+0x132/0x190 [  161.152606]  ? nfsd4_encode_dirent_fattr+0x380/0x380 [  161.153516]  ? nfsd_unlink+0x380/0x380 [  161.154256]  ? override_creds+0x45/0x60 [  161.155006]  nfsd4_encode_readdir+0x21a/0x3d0 [  161.155850]  ? nfsd4_encode_readlink+0x210/0x210 [  161.156731]  ? write_bytes_to_xdr_buf+0x97/0xe0 [  161.157598]  ? __write_bytes_to_xdr_buf+0xd0/0xd0 [  161.158494]  ? lock_downgrade+0x90/0x90 [  161.159232]  ? nfs4svc_decode_voidarg+0x10/0x10 [  161.160092]  nfsd4_encode_operation+0x15a/0x440 [  161.160959]  nfsd4_proc_compound+0x718/0xe90 [  161.161818]  nfsd_dispatch+0x18e/0x2c0 [  161.162586]  svc_process_common+0x786/0xc50 [  161.163403]  ? nfsd_svc+0x380/0x380 [  161.164137]  ? svc_printk+0x160/0x160 [  161.164846]  ? svc_xprt_do_enqueue.part.0+0x365/0x380 [  161.165808]  ? nfsd_svc+0x380/0x380 [  161.166523]  ? rcu_is_watching+0x23/0x40 [  161.167309]  svc_process+0x1a5/0x200 [  161.168019]  nfsd+0x1f5/0x380 [  161.168663]  ? nfsd_shutdown_threads+0x260/0x260 [  161.169554]  kthread+0x1c4/0x210 [  161.170224]  ? kthread_insert_work_sanity_check+0x80/0x80 [  161.171246]  ret_from_fork+0x1f/0x30(CVE-2024-49875)In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Initialize get_bytes_per_element&#39;s default to 1  Variables, used as denominators and maybe not assigned to other values, should not be 0. bytes_per_element_y &amp; bytes_per_element_c are initialized by get_bytes_per_element() which should never return 0.  This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.(CVE-2024-49892)In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Fix index out of bounds in degamma hardware format translation  Fixes index out of bounds issue in `cm_helper_translate_curve_to_degamma_hw_format` function. The issue could occur when the index &#39;i&#39; exceeds the number of transfer function points (TRANSFER_FUNC_POINTS).  The fix adds a check to ensure &#39;i&#39; is within bounds before accessing the transfer function points. If &#39;i&#39; is out of bounds the function returns false to indicate an error.  Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow &#39;output_tf-&gt;tf_pts.red&#39; 1025 &lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow &#39;output_tf-&gt;tf_pts.green&#39; 1025 &lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow &#39;output_tf-&gt;tf_pts.blue&#39; 1025 &lt;= s32max(CVE-2024-49894)In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format translation  This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_degamma_hw_format` function in the DCN30 color  management module. The issue could occur when the index &#39;i&#39; exceeds the  number of transfer function points (TRANSFER_FUNC_POINTS).  The fix adds a check to ensure &#39;i&#39; is within bounds before accessing the transfer function points. If &#39;i&#39; is out of bounds, the function returns false to indicate an error.  Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:338 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow &#39;output_tf-&gt;tf_pts.red&#39; 1025 &lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:339 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow &#39;output_tf-&gt;tf_pts.green&#39; 1025 &lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:340 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow &#39;output_tf-&gt;tf_pts.blue&#39; 1025 &lt;= s32max(CVE-2024-49895)In the Linux kernel, the following vulnerability has been resolved:  jfs: Fix uninit-value access of new_ea in ea_buffer  syzbot reports that lzo1x_1_do_compress is using uninit-value:  ===================================================== BUG: KMSAN: uninit-value in lzo1x_1_do_compress+0x19f9/0x2510 lib/lzo/lzo1x_compress.c:178  ...  Uninit was stored to memory at:  ea_put fs/jfs/xattr.c:639 [inline]  ...  Local variable ea_buf created at:  __jfs_setxattr+0x5d/0x1ae0 fs/jfs/xattr.c:662  __jfs_xattr_set+0xe6/0x1f0 fs/jfs/xattr.c:934  =====================================================  The reason is ea_buf-&gt;new_ea is not initialized properly.  Fix this by using memset to empty its content at the beginning in ea_get().(CVE-2024-49900)In the Linux kernel, the following vulnerability has been resolved:  jfs: check if leafidx greater than num leaves per dmap tree  syzbot report a out of bounds in dbSplit, it because dmt_leafidx greater than num leaves per dmap tree, add a checking for dmt_leafidx in dbFindLeaf.  Shaggy: Modified sanity check to apply to control pages as well as leaf pages.(CVE-2024-49902)In the Linux kernel, the following vulnerability has been resolved:  jfs: Fix uaf in dbFreeBits  [syzbot reported] ================================================================== BUG: KASAN: slab-use-after-free in __mutex_lock_common kernel/locking/mutex.c:587 [inline] BUG: KASAN: slab-use-after-free in __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 Read of size 8 at addr ffff8880229254b0 by task syz-executor357/5216  CPU: 0 UID: 0 PID: 5216 Comm: syz-executor357 Not tainted 6.11.0-rc3-syzkaller-00156-gd7a5aa4b3c00 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024 Call Trace:  &lt;TASK&gt;  __dump_stack lib/dump_stack.c:93 [inline]  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119  print_address_description mm/kasan/report.c:377 [inline]  print_report+0x169/0x550 mm/kasan/report.c:488  kasan_report+0x143/0x180 mm/kasan/report.c:601  __mutex_lock_common kernel/locking/mutex.c:587 [inline]  __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752  dbFreeBits+0x7ea/0xd90 fs/jfs/jfs_dmap.c:2390  dbFreeDmap fs/jfs/jfs_dmap.c:2089 [inline]  dbFree+0x35b/0x680 fs/jfs/jfs_dmap.c:409  dbDiscardAG+0x8a9/0xa20 fs/jfs/jfs_dmap.c:1650  jfs_ioc_trim+0x433/0x670 fs/jfs/jfs_discard.c:100  jfs_ioctl+0x2d0/0x3e0 fs/jfs/ioctl.c:131  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  Freed by task 5218:  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]  kfree+0x149/0x360 mm/slub.c:4594  dbUnmount+0x11d/0x190 fs/jfs/jfs_dmap.c:278  jfs_mount_rw+0x4ac/0x6a0 fs/jfs/jfs_mount.c:247  jfs_remount+0x3d1/0x6b0 fs/jfs/super.c:454  reconfigure_super+0x445/0x880 fs/super.c:1083  vfs_cmd_reconfigure fs/fsopen.c:263 [inline]  vfs_fsconfig_locked fs/fsopen.c:292 [inline]  __do_sys_fsconfig fs/fsopen.c:473 [inline]  __se_sys_fsconfig+0xb6e/0xf80 fs/fsopen.c:345  do_syscall_x64 arch/x86/entry/common.c:52 [inline]  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  [Analysis] There are two paths (dbUnmount and jfs_ioc_trim) that generate race condition when accessing bmap, which leads to the occurrence of uaf.  Use the lock s_umount to synchronize them, in order to avoid uaf caused by race condition.(CVE-2024-49903)In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Add NULL check for function pointer in dcn20_set_output_transfer_func  This commit adds a null check for the set_output_gamma function pointer in the dcn20_set_output_transfer_func function. Previously, set_output_gamma was being checked for null at line 1030, but then it was being dereferenced without any null check at line 1048. This could potentially lead to a null pointer dereference error if set_output_gamma is null.  To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma at line 1048.(CVE-2024-49911)In the Linux kernel, the following vulnerability has been resolved:  x86/ioapic: Handle allocation failures gracefully  Breno observed panics when using failslab under certain conditions during runtime:     can not alloc irq_pin_list (-1,0,20)    Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed     panic+0x4e9/0x590    mp_irqdomain_alloc+0x9ab/0xa80    irq_domain_alloc_irqs_locked+0x25d/0x8d0    __irq_domain_alloc_irqs+0x80/0x110    mp_map_pin_to_irq+0x645/0x890    acpi_register_gsi_ioapic+0xe6/0x150    hpet_open+0x313/0x480  That&#39;s a pointless panic which is a leftover of the historic IO/APIC code which panic&#39;ed during early boot when the interrupt allocation failed.  The only place which might justify panic is the PIT/HPET timer_check() code which tries to figure out whether the timer interrupt is delivered through the IO/APIC. But that code does not require to handle interrupt allocation failures. If the interrupt cannot be allocated then timer delivery fails and it either panics due to that or falls back to legacy mode.  Cure this by removing the panic wrapper around __add_pin_to_irq_node() and making mp_irqdomain_alloc() aware of the failure condition and handle it as any other failure in this function gracefully.(CVE-2024-49927)In the Linux kernel, the following vulnerability has been resolved:  jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error  In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail() to recover some journal space. But if an error occurs while executing jbd2_cleanup_journal_tail() (e.g., an EIO), we don&#39;t stop waiting for free space right away, we try other branches, and if j_committing_transaction is NULL (i.e., the tid is 0), we will get the following complain:  ============================================ JBD2: I/O error when updating journal superblock for sdd-8. __jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available __jbd2_log_wait_for_space: no way to get more journal space in sdd-8 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0 Modules linked in: CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1 RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0 Call Trace:  &lt;TASK&gt;  add_transaction_credits+0x5d1/0x5e0  start_this_handle+0x1ef/0x6a0  jbd2__journal_start+0x18b/0x340  ext4_dirty_inode+0x5d/0xb0  __mark_inode_dirty+0xe4/0x5d0  generic_update_time+0x60/0x70 [...] ============================================  So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to clean up at the moment, continue to try to reclaim free space in other ways.  Note that this fix relies on commit 6f6a6fda2945 (&#34;jbd2: fix ocfs2 corrupt when updating journal superblock fails&#34;) to make jbd2_cleanup_journal_tail return the correct error code.(CVE-2024-49959)In the Linux kernel, the following vulnerability has been resolved:  ocfs2: remove unreasonable unlock in ocfs2_read_blocks  Patch series &#34;Misc fixes for ocfs2_read_blocks&#34;, v5.  This series contains 2 fixes for ocfs2_read_blocks().  The first patch fix the issue reported by syzbot, which detects bad unlock balance in ocfs2_read_blocks().  The second patch fixes an issue reported by Heming Zhao when reviewing above fix.   This patch (of 2):  There was a lock release before exiting, so remove the unreasonable unlock.(CVE-2024-49965)In the Linux kernel, the following vulnerability has been resolved:  ocfs2: cancel dqi_sync_work before freeing oinfo  ocfs2_global_read_info() will initialize and schedule dqi_sync_work at the end, if error occurs after successfully reading global quota, it will trigger the following warning with CONFIG_DEBUG_OBJECTS_* enabled:  ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timer_list hint: qsync_work_fn+0x0/0x16c  This reports that there is an active delayed work when freeing oinfo in error handling, so cancel dqi_sync_work first.  BTW, return status instead of -1 when .read_file_info fails.(CVE-2024-49966)In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Fix index out of bounds in DCN30 color transformation  This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_hw_format` function in the DCN30 color management module. The issue could occur when the index &#39;i&#39; exceeds the number of transfer function points (TRANSFER_FUNC_POINTS).  The fix adds a check to ensure &#39;i&#39; is within bounds before accessing the transfer function points. If &#39;i&#39; is out of bounds, the function returns false to indicate an error.  drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:180 cm3_helper_translate_curve_to_hw_format() error: buffer overflow &#39;output_tf-&gt;tf_pts.red&#39; 1025 &lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:181 cm3_helper_translate_curve_to_hw_format() error: buffer overflow &#39;output_tf-&gt;tf_pts.green&#39; 1025 &lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:182 cm3_helper_translate_curve_to_hw_format() error: buffer overflow &#39;output_tf-&gt;tf_pts.blue&#39; 1025 &lt;= s32max(CVE-2024-49969)In the Linux kernel, the following vulnerability has been resolved:  NFSD: Limit the number of concurrent async COPY operations  Nothing appears to limit the number of concurrent async COPY operations that clients can start. In addition, AFAICT each async COPY can copy an unlimited number of 4MB chunks, so can run for a long time. Thus IMO async COPY can become a DoS vector.  Add a restriction mechanism that bounds the number of concurrent background COPY operations. Start simple and try to be fair -- this patch implements a per-namespace limit.  An async COPY request that occurs while this limit is exceeded gets NFS4ERR_DELAY. The requesting client can choose to send the request again after a delay or fall back to a traditional read/write style copy.  If there is need to make the mechanism more sophisticated, we can visit that in future patches.(CVE-2024-49974)In the Linux kernel, the following vulnerability has been resolved:  i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume  In case there is any sort of clock controller attached to this I2C bus controller, for example Versaclock or even an AIC32x4 I2C codec, then an I2C transfer triggered from the clock controller clk_ops .prepare callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex.  This is because the clock controller first grabs the prepare_lock mutex and then performs the prepare operation, including its I2C access. The I2C access resumes this I2C bus controller via .runtime_resume callback, which calls clk_prepare_enable(), which attempts to grab the prepare_lock mutex again and deadlocks.  Since the clock are already prepared since probe() and unprepared in remove(), use simple clk_enable()/clk_disable() calls to enable and disable the clock on runtime suspend and resume, to avoid hitting the prepare_lock mutex.(CVE-2024-49985)In the Linux kernel, the following vulnerability has been resolved:  scsi: fnic: Move flush_work initialization out of if block  After commit 379a58caa199 (&#34;scsi: fnic: Move fnic_fnic_flush_tx() to a work queue&#34;), it can happen that a work item is sent to an uninitialized work queue.  This may has the effect that the item being queued is never actually queued, and any further actions depending on it will not proceed.  The following warning is observed while the fnic driver is loaded:  kernel: WARNING: CPU: 11 PID: 0 at ../kernel/workqueue.c:1524 __queue_work+0x373/0x410 kernel:  &lt;IRQ&gt; kernel:  queue_work_on+0x3a/0x50 kernel:  fnic_wq_copy_cmpl_handler+0x54a/0x730 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel:  fnic_isr_msix_wq_copy+0x2d/0x60 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel:  __handle_irq_event_percpu+0x36/0x1a0 kernel:  handle_irq_event_percpu+0x30/0x70 kernel:  handle_irq_event+0x34/0x60 kernel:  handle_edge_irq+0x7e/0x1a0 kernel:  __common_interrupt+0x3b/0xb0 kernel:  common_interrupt+0x58/0xa0 kernel:  &lt;/IRQ&gt;  It has been observed that this may break the rediscovery of Fibre Channel devices after a temporary fabric failure.  This patch fixes it by moving the work queue initialization out of an if block in fnic_probe().(CVE-2024-50025)In the Linux kernel, the following vulnerability has been resolved:  net: do not delay dst_entries_add() in dst_release()  dst_entries_add() uses per-cpu data that might be freed at netns dismantle from ip6_route_net_exit() calling dst_entries_destroy()  Before ip6_route_net_exit() can be called, we release all the dsts associated with this netns, via calls to dst_release(), which waits an rcu grace period before calling dst_destroy()  dst_entries_add() use in dst_destroy() is racy, because dst_entries_destroy() could have been called already.  Decrementing the number of dsts must happen sooner.  Notes:  1) in CONFIG_XFRM case, dst_destroy() can call    dst_release_immediate(child), this might also cause UAF    if the child does not have DST_NOCOUNT set.    IPSEC maintainers might take a look and see how to address this.  2) There is also discussion about removing this count of dst,    which might happen in future kernels.(CVE-2024-50036)In the Linux kernel, the following vulnerability has been resolved:  NFSv4: Prevent NULL-pointer dereference in nfs42_complete_copies()  On the node of an NFS client, some files saved in the mountpoint of the NFS server were copied to another location of the same NFS server. Accidentally, the nfs42_complete_copies() got a NULL-pointer dereference crash with the following syslog:  [232064.838881] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232064.839360] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232066.588183] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 [232066.588586] Mem abort info: [232066.588701]   ESR = 0x0000000096000007 [232066.588862]   EC = 0x25: DABT (current EL), IL = 32 bits [232066.589084]   SET = 0, FnV = 0 [232066.589216]   EA = 0, S1PTW = 0 [232066.589340]   FSC = 0x07: level 3 translation fault [232066.589559] Data abort info: [232066.589683]   ISV = 0, ISS = 0x00000007 [232066.589842]   CM = 0, WnR = 0 [232066.589967] user pgtable: 64k pages, 48-bit VAs, pgdp=00002000956ff400 [232066.590231] [0000000000000058] pgd=08001100ae100003, p4d=08001100ae100003, pud=08001100ae100003, pmd=08001100b3c00003, pte=0000000000000000 [232066.590757] Internal error: Oops: 96000007 [#1] SMP [232066.590958] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm vhost_net vhost vhost_iotlb tap tun ipt_rpfilter xt_multiport ip_set_hash_ip ip_set_hash_net xfrm_interface xfrm6_tunnel tunnel4 tunnel6 esp4 ah4 wireguard libcurve25519_generic veth xt_addrtype xt_set nf_conntrack_netlink ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_bitmap_port ip_set_hash_ipport dummy ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs iptable_filter sch_ingress nfnetlink_cttimeout vport_gre ip_gre ip_tunnel gre vport_geneve geneve vport_vxlan vxlan ip6_udp_tunnel udp_tunnel openvswitch nf_conncount dm_round_robin dm_service_time dm_multipath xt_nat xt_MASQUERADE nft_chain_nat nf_nat xt_mark xt_conntrack xt_comment nft_compat nft_counter nf_tables nfnetlink ocfs2 ocfs2_nodemanager ocfs2_stackglue iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipmi_ssif nbd overlay 8021q garp mrp bonding tls rfkill sunrpc ext4 mbcache jbd2 [232066.591052]  vfat fat cas_cache cas_disk ses enclosure scsi_transport_sas sg acpi_ipmi ipmi_si ipmi_devintf ipmi_msghandler ip_tables vfio_pci vfio_pci_core vfio_virqfd vfio_iommu_type1 vfio dm_mirror dm_region_hash dm_log dm_mod nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp llc fuse xfs libcrc32c ast drm_vram_helper qla2xxx drm_kms_helper syscopyarea crct10dif_ce sysfillrect ghash_ce sysimgblt sha2_ce fb_sys_fops cec sha256_arm64 sha1_ce drm_ttm_helper ttm nvme_fc igb sbsa_gwdt nvme_fabrics drm nvme_core i2c_algo_bit i40e scsi_transport_fc megaraid_sas aes_neon_bs [232066.596953] CPU: 6 PID: 4124696 Comm: 10.253.166.125- Kdump: loaded Not tainted 5.15.131-9.cl9_ocfs2.aarch64 #1 [232066.597356] Hardware name: Great Wall .\x93\x8e...RF6260 V5/GWMSSE2GL1T, BIOS T656FBE_V3.0.18 2024-01-06 [232066.597721] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [232066.598034] pc : nfs4_reclaim_open_state+0x220/0x800 [nfsv4] [232066.598327] lr : nfs4_reclaim_open_state+0x12c/0x800 [nfsv4] [232066.598595] sp : ffff8000f568fc70 [232066.598731] x29: ffff8000f568fc70 x28: 0000000000001000 x27: ffff21003db33000 [232066.599030] x26: ffff800005521ae0 x25: ffff0100f98fa3f0 x24: 0000000000000001 [232066.599319] x23: ffff800009920008 x22: ffff21003db33040 x21: ffff21003db33050 [232066.599628] x20: ffff410172fe9e40 x19: ffff410172fe9e00 x18: 0000000000000000 [232066.599914] x17: 0000000000000000 x16: 0000000000000004 x15: 0000000000000000 [232066.600195] x14: 0000000000000000 x13: ffff800008e685a8 x12: 00000000eac0c6e6 [232066.600498] x11: 00000000000000 ---truncated---(CVE-2024-50046)In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Check null pointer before dereferencing se  [WHAT &amp; HOW] se is null checked previously in the same function, indicating it might be null; therefore, it must be checked when used again.  This fixes 1 FORWARD_NULL issue reported by Coverity.(CVE-2024-50049)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="bpftool" release="234.0.0.133.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-234.0.0.133.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="234.0.0.133.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-234.0.0.133.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="234.0.0.133.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-234.0.0.133.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="234.0.0.133.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-234.0.0.133.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="234.0.0.133.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-234.0.0.133.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="234.0.0.133.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-234.0.0.133.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="234.0.0.133.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-234.0.0.133.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="234.0.0.133.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-234.0.0.133.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="234.0.0.133.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-234.0.0.133.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="234.0.0.133.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-234.0.0.133.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="234.0.0.133.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-234.0.0.133.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="234.0.0.133.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-234.0.0.133.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="234.0.0.133.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-234.0.0.133.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="234.0.0.133.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-234.0.0.133.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="234.0.0.133.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-234.0.0.133.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="234.0.0.133.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-234.0.0.133.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="234.0.0.133.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-234.0.0.133.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="234.0.0.133.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-234.0.0.133.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="234.0.0.133.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-234.0.0.133.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="234.0.0.133.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-234.0.0.133.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="234.0.0.133.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-234.0.0.133.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="234.0.0.133.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-234.0.0.133.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="234.0.0.133.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-234.0.0.133.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="234.0.0.133.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-234.0.0.133.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="234.0.0.133.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-234.0.0.133.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="234.0.0.133.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-234.0.0.133.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="234.0.0.133.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-234.0.0.133.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="234.0.0.133.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-234.0.0.133.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="234.0.0.133.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-234.0.0.133.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="234.0.0.133.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-234.0.0.133.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2326</id>
          <title>An update for vorbis-tools is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-11-01"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-43361" id="CVE-2023-43361" title="CVE-2023-43361" type="cve"></reference>
          </references>
          <description>Buffer Overflow vulnerability in Vorbis-tools v.1.4.2 allows a local attacker to execute arbitrary code and cause a denial of service during the conversion of wav files to ogg files.(CVE-2023-43361)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="vorbis-tools" release="4.oe2203sp4" version="1.4.2">
                         <filename>vorbis-tools-1.4.2-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="vorbis-tools-debuginfo" release="4.oe2203sp4" version="1.4.2">
                         <filename>vorbis-tools-debuginfo-1.4.2-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="vorbis-tools-debugsource" release="4.oe2203sp4" version="1.4.2">
                         <filename>vorbis-tools-debugsource-1.4.2-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="vorbis-tools-help" release="4.oe2203sp4" version="1.4.2">
                         <filename>vorbis-tools-help-1.4.2-4.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="vorbis-tools" release="4.oe2203sp4" version="1.4.2">
                         <filename>vorbis-tools-1.4.2-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="vorbis-tools-debuginfo" release="4.oe2203sp4" version="1.4.2">
                         <filename>vorbis-tools-debuginfo-1.4.2-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="vorbis-tools-debugsource" release="4.oe2203sp4" version="1.4.2">
                         <filename>vorbis-tools-debugsource-1.4.2-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2327</id>
          <title>An update for zziplib is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-11-01"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39134" id="CVE-2024-39134" title="CVE-2024-39134" type="cve"></reference>
          </references>
          <description>A Stack Buffer Overflow vulnerability in zziplibv 0.13.77 allows attackers to cause a denial of service via the __zzip_fetch_disk_trailer() function at /zzip/zip.c.(CVE-2024-39134)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="zziplib" release="6.oe2203sp4" version="0.13.71">
                         <filename>zziplib-0.13.71-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="zziplib-debuginfo" release="6.oe2203sp4" version="0.13.71">
                         <filename>zziplib-debuginfo-0.13.71-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="zziplib-debugsource" release="6.oe2203sp4" version="0.13.71">
                         <filename>zziplib-debugsource-0.13.71-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="zziplib-devel" release="6.oe2203sp4" version="0.13.71">
                         <filename>zziplib-devel-0.13.71-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="zziplib-help" release="6.oe2203sp4" version="0.13.71">
                         <filename>zziplib-help-0.13.71-6.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="zziplib" release="6.oe2203sp4" version="0.13.71">
                         <filename>zziplib-0.13.71-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="zziplib-debuginfo" release="6.oe2203sp4" version="0.13.71">
                         <filename>zziplib-debuginfo-0.13.71-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="zziplib-debugsource" release="6.oe2203sp4" version="0.13.71">
                         <filename>zziplib-debugsource-0.13.71-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="zziplib-devel" release="6.oe2203sp4" version="0.13.71">
                         <filename>zziplib-devel-0.13.71-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2328</id>
          <title>An update for botan2 is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-11-01"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50382" id="CVE-2024-50382" title="CVE-2024-50382" type="cve"></reference>
          </references>
          <description>Botan before 3.6.0, when certain LLVM versions are used, has compiler-induced secret-dependent control flow in lib/utils/ghash/ghash.cpp in GHASH in AES-GCM. There is a branch instead of an XOR with carry. This was observed for Clang in LLVM 15 on RISC-V.(CVE-2024-50382)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="botan2" release="4.oe2203sp4" version="2.19.3">
                         <filename>botan2-2.19.3-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="botan2-debuginfo" release="4.oe2203sp4" version="2.19.3">
                         <filename>botan2-debuginfo-2.19.3-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="botan2-debugsource" release="4.oe2203sp4" version="2.19.3">
                         <filename>botan2-debugsource-2.19.3-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="botan2-devel" release="4.oe2203sp4" version="2.19.3">
                         <filename>botan2-devel-2.19.3-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-botan2" release="4.oe2203sp4" version="2.19.3">
                         <filename>python3-botan2-2.19.3-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="botan2-doc" release="4.oe2203sp4" version="2.19.3">
                         <filename>botan2-doc-2.19.3-4.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="botan2" release="4.oe2203sp4" version="2.19.3">
                         <filename>botan2-2.19.3-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="botan2-debuginfo" release="4.oe2203sp4" version="2.19.3">
                         <filename>botan2-debuginfo-2.19.3-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="botan2-debugsource" release="4.oe2203sp4" version="2.19.3">
                         <filename>botan2-debugsource-2.19.3-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="botan2-devel" release="4.oe2203sp4" version="2.19.3">
                         <filename>botan2-devel-2.19.3-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-botan2" release="4.oe2203sp4" version="2.19.3">
                         <filename>python3-botan2-2.19.3-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2331</id>
          <title>An update for NetworkManager-libreswan is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-11-01"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-9050" id="CVE-2024-9050" title="CVE-2024-9050" type="cve"></reference>
          </references>
          <description>A flaw was found in the libreswan client plugin for NetworkManager (NetkworkManager-libreswan), where it fails to properly sanitize the VPN configuration from the local unprivileged user. In this configuration, composed by a key-value format, the plugin fails to escape special characters, leading the application to interpret values as keys. One of the most critical parameters that could be abused by a malicious user is the `leftupdown`key. This key takes an executable command as a value and is used to specify what executes as a callback in NetworkManager-libreswan to retrieve configuration settings back to NetworkManager. As NetworkManager uses Polkit to allow an unprivileged user to control the system&#39;s network configuration, a malicious actor could achieve local privilege escalation and potential code execution as root in the targeted machine.(CVE-2024-9050)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="NetworkManager-libreswan" release="1.oe2203sp4" version="1.2.24">
                         <filename>NetworkManager-libreswan-1.2.24-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="NetworkManager-libreswan-debuginfo" release="1.oe2203sp4" version="1.2.24">
                         <filename>NetworkManager-libreswan-debuginfo-1.2.24-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="NetworkManager-libreswan-debugsource" release="1.oe2203sp4" version="1.2.24">
                         <filename>NetworkManager-libreswan-debugsource-1.2.24-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="NetworkManager-libreswan-gnome" release="1.oe2203sp4" version="1.2.24">
                         <filename>NetworkManager-libreswan-gnome-1.2.24-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="NetworkManager-libreswan" release="1.oe2203sp4" version="1.2.24">
                         <filename>NetworkManager-libreswan-1.2.24-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="NetworkManager-libreswan-debuginfo" release="1.oe2203sp4" version="1.2.24">
                         <filename>NetworkManager-libreswan-debuginfo-1.2.24-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="NetworkManager-libreswan-debugsource" release="1.oe2203sp4" version="1.2.24">
                         <filename>NetworkManager-libreswan-debugsource-1.2.24-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="NetworkManager-libreswan-gnome" release="1.oe2203sp4" version="1.2.24">
                         <filename>NetworkManager-libreswan-gnome-1.2.24-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2336</id>
          <title>An update for python-waitress is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2024-11-01"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49768" id="CVE-2024-49768" title="CVE-2024-49768" type="cve"></reference>
          </references>
          <description>(CVE-2024-49768)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="python3-waitress" release="4.oe2203sp4" version="2.0.0">
                         <filename>python3-waitress-2.0.0-4.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2337</id>
          <title>An update for hdf5 is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2024-11-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2018-13871" id="CVE-2018-13871" title="CVE-2018-13871" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2018-13875" id="CVE-2018-13875" title="CVE-2018-13875" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2018-14034" id="CVE-2018-14034" title="CVE-2018-14034" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29157" id="CVE-2024-29157" title="CVE-2024-29157" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29158" id="CVE-2024-29158" title="CVE-2024-29158" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29159" id="CVE-2024-29159" title="CVE-2024-29159" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29160" id="CVE-2024-29160" title="CVE-2024-29160" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29161" id="CVE-2024-29161" title="CVE-2024-29161" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29162" id="CVE-2024-29162" title="CVE-2024-29162" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29163" id="CVE-2024-29163" title="CVE-2024-29163" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29164" id="CVE-2024-29164" title="CVE-2024-29164" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29165" id="CVE-2024-29165" title="CVE-2024-29165" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32605" id="CVE-2024-32605" title="CVE-2024-32605" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32607" id="CVE-2024-32607" title="CVE-2024-32607" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32608" id="CVE-2024-32608" title="CVE-2024-32608" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32609" id="CVE-2024-32609" title="CVE-2024-32609" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32610" id="CVE-2024-32610" title="CVE-2024-32610" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32611" id="CVE-2024-32611" title="CVE-2024-32611" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32612" id="CVE-2024-32612" title="CVE-2024-32612" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32613" id="CVE-2024-32613" title="CVE-2024-32613" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32614" id="CVE-2024-32614" title="CVE-2024-32614" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32615" id="CVE-2024-32615" title="CVE-2024-32615" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32616" id="CVE-2024-32616" title="CVE-2024-32616" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32617" id="CVE-2024-32617" title="CVE-2024-32617" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32618" id="CVE-2024-32618" title="CVE-2024-32618" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32619" id="CVE-2024-32619" title="CVE-2024-32619" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32620" id="CVE-2024-32620" title="CVE-2024-32620" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32621" id="CVE-2024-32621" title="CVE-2024-32621" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32622" id="CVE-2024-32622" title="CVE-2024-32622" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32623" id="CVE-2024-32623" title="CVE-2024-32623" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32624" id="CVE-2024-32624" title="CVE-2024-32624" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-33873" id="CVE-2024-33873" title="CVE-2024-33873" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-33874" id="CVE-2024-33874" title="CVE-2024-33874" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-33875" id="CVE-2024-33875" title="CVE-2024-33875" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-33876" id="CVE-2024-33876" title="CVE-2024-33876" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-33877" id="CVE-2024-33877" title="CVE-2024-33877" type="cve"></reference>
          </references>
          <description>An issue was discovered in the HDF HDF5 1.8.20 library. There is a heap-based buffer overflow in the function H5FL_blk_malloc in H5FL.c.(CVE-2018-13871)An issue was discovered in the HDF HDF5 1.8.20 library. There is an out-of-bounds read in the function H5VM_memcpyvv in H5VM.c.(CVE-2018-13875)An issue was discovered in the HDF HDF5 1.8.20 library. There is an out of bounds read in the function H5O_pline_reset in H5Opline.c.(CVE-2018-14034)HDF5 through 1.14.3 contains a heap buffer overflow in H5HG_read, resulting in the corruption of the instruction pointer and causing denial of service or potential code execution.(CVE-2024-29157)HDF5 through 1.14.3 contains a stack buffer overflow in H5FL_arr_malloc, resulting in the corruption of the instruction pointer and causing denial of service or potential code execution.(CVE-2024-29158)HDF5 through 1.14.3 contains a buffer overflow in H5Z__filter_scaleoffset, resulting in the corruption of the instruction pointer and causing denial of service or potential code execution.(CVE-2024-29159)HDF5 through 1.14.3 contains a heap buffer overflow in H5HG__cache_heap_deserialize, resulting in the corruption of the instruction pointer and causing denial of service or potential code execution.(CVE-2024-29160)HDF5 through 1.14.3 contains a heap buffer overflow in H5A__attr_release_table, resulting in the corruption of the instruction pointer and causing denial of service or potential code execution.(CVE-2024-29161)HDF5 through 1.13.3 and/or 1.14.2 contains a stack buffer overflow in H5HG_read, resulting in denial of service or potential code execution.(CVE-2024-29162)HDF5 through 1.14.3 contains a heap buffer overflow in H5T__bit_find, resulting in the corruption of the instruction pointer and causing denial of service or potential code execution.(CVE-2024-29163)HDF5 through 1.14.3 contains a stack buffer overflow in H5R__decode_heap, resulting in the corruption of the instruction pointer and causing denial of service or potential code execution.(CVE-2024-29164)HDF5 through 1.14.3 contains a buffer overflow in H5Z__filter_fletcher32, resulting in the corruption of the instruction pointer and causing denial of service or potential code execution.(CVE-2024-29165)HDF5 Library through 1.14.3 has a heap-based buffer over-read in H5VM_memcpyvv in H5VM.c (called from H5D__compact_readvv in H5Dcompact.c).(CVE-2024-32605)HDF5 Library through 1.14.3 has a SEGV in H5A__close in H5Aint.c, resulting in the corruption of the instruction pointer.(CVE-2024-32607)HDF5 library through 1.14.3 has memory corruption in H5A__close resulting in the corruption of the instruction pointer and causing denial of service or potential code execution.(CVE-2024-32608)HDF5 Library through 1.14.3 allows stack consumption in the function H5E_printf_stack in H5Eint.c.(CVE-2024-32609)HDF5 Library through 1.14.3 has a SEGV in H5T_close_real in H5T.c, resulting in a corrupted instruction pointer.(CVE-2024-32610)HDF5 Library through 1.14.3 may use an uninitialized value in H5A__attr_release_table in H5Aint.c.(CVE-2024-32611)HDF5 Library through 1.14.3 contains a heap-based buffer over-read in H5HL__fl_deserialize in H5HLcache.c, resulting in the corruption of the instruction pointer, a different vulnerability than CVE-2024-32613.(CVE-2024-32612)HDF5 Library through 1.14.3 contains a heap-based buffer over-read in the function H5HL__fl_deserialize in H5HLcache.c, a different vulnerability than CVE-2024-32612.(CVE-2024-32613)HDF5 Library through 1.14.3 has a SEGV in H5VM_memcpyvv in H5VM.c.(CVE-2024-32614)HDF5 Library through 1.14.3 contains a heap-based buffer overflow in H5Z__nbit_decompress_one_byte in H5Znbit.c, caused by the earlier use of an initialized pointer.(CVE-2024-32615)HDF5 Library through 1.14.3 contains a heap-based buffer over-read in H5O__dtype_encode_helper in H5Odtype.c.(CVE-2024-32616)HDF5 Library through 1.14.3 contains a heap-based buffer over-read caused by the unsafe use of strdup in H5MM_xstrdup in H5MM.c (called from H5G__ent_to_link in H5Glink.c).(CVE-2024-32617)HDF5 Library through 1.14.3 contains a heap-based buffer overflow in H5T__get_native_type in H5Tnative.c, resulting in the corruption of the instruction pointer.(CVE-2024-32618)HDF5 Library through 1.14.3 contains a heap-based buffer overflow in H5T_copy_reopen in H5T.c, resulting in the corruption of the instruction pointer.(CVE-2024-32619)HDF5 Library through 1.14.3 contains a heap-based buffer over-read in H5F_addr_decode_len in H5Fint.c, resulting in the corruption of the instruction pointer.(CVE-2024-32620)HDF5 Library through 1.14.3 contains a heap-based buffer overflow in H5HG_read in H5HG.c (called from H5VL__native_blob_get in H5VLnative_blob.c), resulting in the corruption of the instruction pointer.(CVE-2024-32621)HDF5 Library through 1.14.3 contains a out-of-bounds read operation in H5FL_arr_malloc in H5FL.c (called from H5S_set_extent_simple in H5S.c).(CVE-2024-32622)HDF5 Library through 1.14.3 contains a heap-based buffer overflow in H5VM_array_fill in H5VM.c (called from H5S_select_elements in H5Spoint.c).(CVE-2024-32623)HDF5 Library through 1.14.3 contains a heap-based buffer overflow in H5T__ref_mem_setnull in H5Tref.c (called from H5T__conv_ref in H5Tconv.c), resulting in the corruption of the instruction pointer.(CVE-2024-32624)HDF5 Library through 1.14.3 has a heap-based buffer overflow in H5D__scatter_mem in H5Dscatgath.c.(CVE-2024-33873)HDF5 Library through 1.14.3 has a heap buffer overflow in H5O__mtime_new_encode in H5Omtime.c.(CVE-2024-33874)HDF5 Library through 1.14.3 has a heap-based buffer overflow in H5O__layout_encode in H5Olayout.c, resulting in the corruption of the instruction pointer.(CVE-2024-33875)HDF5 Library through 1.14.3 has a heap buffer overflow in H5S__point_deserialize in H5Spoint.c.(CVE-2024-33876)HDF5 Library through 1.14.3 has a heap-based buffer overflow in H5T__conv_struct_opt in H5Tconv.c.(CVE-2024-33877)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="hdf5" release="1.oe2203sp4" version="1.14.5">
                         <filename>hdf5-1.14.5-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hdf5-debuginfo" release="1.oe2203sp4" version="1.14.5">
                         <filename>hdf5-debuginfo-1.14.5-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hdf5-debugsource" release="1.oe2203sp4" version="1.14.5">
                         <filename>hdf5-debugsource-1.14.5-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hdf5-devel" release="1.oe2203sp4" version="1.14.5">
                         <filename>hdf5-devel-1.14.5-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hdf5-mpich" release="1.oe2203sp4" version="1.14.5">
                         <filename>hdf5-mpich-1.14.5-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hdf5-mpich-devel" release="1.oe2203sp4" version="1.14.5">
                         <filename>hdf5-mpich-devel-1.14.5-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hdf5-mpich-static" release="1.oe2203sp4" version="1.14.5">
                         <filename>hdf5-mpich-static-1.14.5-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hdf5-openmpi" release="1.oe2203sp4" version="1.14.5">
                         <filename>hdf5-openmpi-1.14.5-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hdf5-openmpi-devel" release="1.oe2203sp4" version="1.14.5">
                         <filename>hdf5-openmpi-devel-1.14.5-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hdf5-openmpi-static" release="1.oe2203sp4" version="1.14.5">
                         <filename>hdf5-openmpi-static-1.14.5-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hdf5" release="1.oe2203sp4" version="1.14.5">
                         <filename>hdf5-1.14.5-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hdf5-debuginfo" release="1.oe2203sp4" version="1.14.5">
                         <filename>hdf5-debuginfo-1.14.5-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hdf5-debugsource" release="1.oe2203sp4" version="1.14.5">
                         <filename>hdf5-debugsource-1.14.5-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hdf5-devel" release="1.oe2203sp4" version="1.14.5">
                         <filename>hdf5-devel-1.14.5-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hdf5-mpich" release="1.oe2203sp4" version="1.14.5">
                         <filename>hdf5-mpich-1.14.5-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hdf5-mpich-devel" release="1.oe2203sp4" version="1.14.5">
                         <filename>hdf5-mpich-devel-1.14.5-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hdf5-mpich-static" release="1.oe2203sp4" version="1.14.5">
                         <filename>hdf5-mpich-static-1.14.5-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hdf5-openmpi" release="1.oe2203sp4" version="1.14.5">
                         <filename>hdf5-openmpi-1.14.5-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hdf5-openmpi-devel" release="1.oe2203sp4" version="1.14.5">
                         <filename>hdf5-openmpi-devel-1.14.5-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hdf5-openmpi-static" release="1.oe2203sp4" version="1.14.5">
                         <filename>hdf5-openmpi-static-1.14.5-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2341</id>
          <title>An update for ruby is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-11-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49761" id="CVE-2024-49761" title="CVE-2024-49761" type="cve"></reference>
          </references>
          <description>(CVE-2024-49761)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="ruby" release="141.oe2203sp4" version="3.0.3">
                         <filename>ruby-3.0.3-141.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ruby-debuginfo" release="141.oe2203sp4" version="3.0.3">
                         <filename>ruby-debuginfo-3.0.3-141.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ruby-debugsource" release="141.oe2203sp4" version="3.0.3">
                         <filename>ruby-debugsource-3.0.3-141.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ruby-devel" release="141.oe2203sp4" version="3.0.3">
                         <filename>ruby-devel-3.0.3-141.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-bigdecimal" release="141.oe2203sp4" version="3.0.0">
                         <filename>rubygem-bigdecimal-3.0.0-141.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-io-console" release="141.oe2203sp4" version="0.5.7">
                         <filename>rubygem-io-console-0.5.7-141.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-json" release="141.oe2203sp4" version="2.5.1">
                         <filename>rubygem-json-2.5.1-141.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-openssl" release="141.oe2203sp4" version="2.2.1">
                         <filename>rubygem-openssl-2.2.1-141.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-psych" release="141.oe2203sp4" version="3.3.2">
                         <filename>rubygem-psych-3.3.2-141.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="ruby-help" release="141.oe2203sp4" version="3.0.3">
                         <filename>ruby-help-3.0.3-141.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="ruby-irb" release="141.oe2203sp4" version="3.0.3">
                         <filename>ruby-irb-3.0.3-141.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-bundler" release="141.oe2203sp4" version="2.2.32">
                         <filename>rubygem-bundler-2.2.32-141.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-did_you_mean" release="141.oe2203sp4" version="1.5.0">
                         <filename>rubygem-did_you_mean-1.5.0-141.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-minitest" release="141.oe2203sp4" version="5.14.2">
                         <filename>rubygem-minitest-5.14.2-141.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rake" release="141.oe2203sp4" version="13.0.3">
                         <filename>rubygem-rake-13.0.3-141.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rbs" release="141.oe2203sp4" version="1.4.0">
                         <filename>rubygem-rbs-1.4.0-141.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rdoc" release="141.oe2203sp4" version="6.3.3">
                         <filename>rubygem-rdoc-6.3.3-141.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rexml" release="141.oe2203sp4" version="3.2.5">
                         <filename>rubygem-rexml-3.2.5-141.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rss" release="141.oe2203sp4" version="0.2.9">
                         <filename>rubygem-rss-0.2.9-141.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-test-unit" release="141.oe2203sp4" version="3.3.7">
                         <filename>rubygem-test-unit-3.3.7-141.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-typeprof" release="141.oe2203sp4" version="0.15.2">
                         <filename>rubygem-typeprof-0.15.2-141.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygems" release="141.oe2203sp4" version="3.2.32">
                         <filename>rubygems-3.2.32-141.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygems-devel" release="141.oe2203sp4" version="3.2.32">
                         <filename>rubygems-devel-3.2.32-141.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby" release="141.oe2203sp4" version="3.0.3">
                         <filename>ruby-3.0.3-141.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby-debuginfo" release="141.oe2203sp4" version="3.0.3">
                         <filename>ruby-debuginfo-3.0.3-141.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby-debugsource" release="141.oe2203sp4" version="3.0.3">
                         <filename>ruby-debugsource-3.0.3-141.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby-devel" release="141.oe2203sp4" version="3.0.3">
                         <filename>ruby-devel-3.0.3-141.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-bigdecimal" release="141.oe2203sp4" version="3.0.0">
                         <filename>rubygem-bigdecimal-3.0.0-141.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-io-console" release="141.oe2203sp4" version="0.5.7">
                         <filename>rubygem-io-console-0.5.7-141.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-json" release="141.oe2203sp4" version="2.5.1">
                         <filename>rubygem-json-2.5.1-141.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-openssl" release="141.oe2203sp4" version="2.2.1">
                         <filename>rubygem-openssl-2.2.1-141.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-psych" release="141.oe2203sp4" version="3.3.2">
                         <filename>rubygem-psych-3.3.2-141.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2346</id>
          <title>An update for mosquitto is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2024-11-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-10525" id="CVE-2024-10525" title="CVE-2024-10525" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3935" id="CVE-2024-3935" title="CVE-2024-3935" type="cve"></reference>
          </references>
          <description>In Eclipse Mosquitto, from version 1.3.2 through 2.0.18, if a malicious broker sends a crafted SUBACK packet with no reason codes, a client using libmosquitto may make out of bounds memory access when acting in its on_subscribe callback. This affects the mosquitto_sub and mosquitto_rr clients.(CVE-2024-10525)In Eclipse Mosquito, versions from 2.0.0 through 2.0.18, if a Mosquitto broker is configured to create an outgoing bridge connection, and that bridge connection has an incoming topic configured that makes use of topic remapping, then if the remote connection sends a crafted PUBLISH packet to the broker a double free will occur with a subsequent crash of the broker.(CVE-2024-3935)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="mosquitto" release="1.oe2203sp4" version="2.0.20">
                         <filename>mosquitto-2.0.20-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mosquitto-debuginfo" release="1.oe2203sp4" version="2.0.20">
                         <filename>mosquitto-debuginfo-2.0.20-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mosquitto-debugsource" release="1.oe2203sp4" version="2.0.20">
                         <filename>mosquitto-debugsource-2.0.20-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mosquitto-devel" release="1.oe2203sp4" version="2.0.20">
                         <filename>mosquitto-devel-2.0.20-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mosquitto" release="1.oe2203sp4" version="2.0.20">
                         <filename>mosquitto-2.0.20-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mosquitto-debuginfo" release="1.oe2203sp4" version="2.0.20">
                         <filename>mosquitto-debuginfo-2.0.20-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mosquitto-debugsource" release="1.oe2203sp4" version="2.0.20">
                         <filename>mosquitto-debugsource-2.0.20-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mosquitto-devel" release="1.oe2203sp4" version="2.0.20">
                         <filename>mosquitto-devel-2.0.20-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2351</id>
          <title>An update for hadoop is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-11-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-23454" id="CVE-2024-23454" title="CVE-2024-23454" type="cve"></reference>
          </references>
          <description>Apache Hadoop’s RunJar.run() does not set permissions for temporary directory by default. If sensitive data will be present in this file, all the other local users may be able to view the content.This is because, on unix-like systems, the system temporary directory isshared between all local users. As such, files written in this directory,without setting the correct posix permissions explicitly, may be viewableby all other local users.(CVE-2024-23454)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="hadoop-common-native" release="3.oe2203sp4" version="3.3.6">
                         <filename>hadoop-common-native-3.3.6-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hadoop-debuginfo" release="3.oe2203sp4" version="3.3.6">
                         <filename>hadoop-debuginfo-3.3.6-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hadoop-debugsource" release="3.oe2203sp4" version="3.3.6">
                         <filename>hadoop-debugsource-3.3.6-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hadoop-devel" release="3.oe2203sp4" version="3.3.6">
                         <filename>hadoop-devel-3.3.6-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hadoop-yarn" release="3.oe2203sp4" version="3.3.6">
                         <filename>hadoop-yarn-3.3.6-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hadoop-yarn-security" release="3.oe2203sp4" version="3.3.6">
                         <filename>hadoop-yarn-security-3.3.6-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libhdfs" release="3.oe2203sp4" version="3.3.6">
                         <filename>libhdfs-3.3.6-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="hadoop-client" release="3.oe2203sp4" version="3.3.6">
                         <filename>hadoop-client-3.3.6-3.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="hadoop-common" release="3.oe2203sp4" version="3.3.6">
                         <filename>hadoop-common-3.3.6-3.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="hadoop-hdfs" release="3.oe2203sp4" version="3.3.6">
                         <filename>hadoop-hdfs-3.3.6-3.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="hadoop-httpfs" release="3.oe2203sp4" version="3.3.6">
                         <filename>hadoop-httpfs-3.3.6-3.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="hadoop-mapreduce" release="3.oe2203sp4" version="3.3.6">
                         <filename>hadoop-mapreduce-3.3.6-3.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="hadoop-mapreduce-examples" release="3.oe2203sp4" version="3.3.6">
                         <filename>hadoop-mapreduce-examples-3.3.6-3.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="hadoop-maven-plugin" release="3.oe2203sp4" version="3.3.6">
                         <filename>hadoop-maven-plugin-3.3.6-3.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="hadoop-tests" release="3.oe2203sp4" version="3.3.6">
                         <filename>hadoop-tests-3.3.6-3.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hadoop-common-native" release="3.oe2203sp4" version="3.3.6">
                         <filename>hadoop-common-native-3.3.6-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hadoop-debuginfo" release="3.oe2203sp4" version="3.3.6">
                         <filename>hadoop-debuginfo-3.3.6-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hadoop-debugsource" release="3.oe2203sp4" version="3.3.6">
                         <filename>hadoop-debugsource-3.3.6-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hadoop-devel" release="3.oe2203sp4" version="3.3.6">
                         <filename>hadoop-devel-3.3.6-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hadoop-yarn" release="3.oe2203sp4" version="3.3.6">
                         <filename>hadoop-yarn-3.3.6-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hadoop-yarn-security" release="3.oe2203sp4" version="3.3.6">
                         <filename>hadoop-yarn-security-3.3.6-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libhdfs" release="3.oe2203sp4" version="3.3.6">
                         <filename>libhdfs-3.3.6-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2352</id>
          <title>An update for xorg-x11-server is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-11-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-9632" id="CVE-2024-9632" title="CVE-2024-9632" type="cve"></reference>
          </references>
          <description>VUL-0: CVE-2024-9632: xorg-x11-server,xwayland: Heap-based buffer overflow privilege escalation in _XkbSetCompatMap(CVE-2024-9632)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="xorg-x11-server" release="34.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-1.20.11-34.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-Xdmx" release="34.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-Xdmx-1.20.11-34.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-Xephyr" release="34.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-Xephyr-1.20.11-34.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-Xnest" release="34.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-Xnest-1.20.11-34.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-Xvfb" release="34.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-Xvfb-1.20.11-34.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-common" release="34.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-common-1.20.11-34.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-debuginfo" release="34.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-debuginfo-1.20.11-34.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-debugsource" release="34.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-debugsource-1.20.11-34.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-devel" release="34.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-devel-1.20.11-34.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="xorg-x11-server-help" release="34.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-help-1.20.11-34.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="xorg-x11-server-source" release="34.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-source-1.20.11-34.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server" release="34.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-1.20.11-34.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xdmx" release="34.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-Xdmx-1.20.11-34.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xephyr" release="34.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-Xephyr-1.20.11-34.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xnest" release="34.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-Xnest-1.20.11-34.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xvfb" release="34.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-Xvfb-1.20.11-34.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-common" release="34.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-common-1.20.11-34.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-debuginfo" release="34.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-debuginfo-1.20.11-34.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-debugsource" release="34.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-debugsource-1.20.11-34.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-devel" release="34.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-devel-1.20.11-34.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2353</id>
          <title>An update for undertow is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-11-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-3690" id="CVE-2021-3690" title="CVE-2021-3690" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5379" id="CVE-2023-5379" title="CVE-2023-5379" type="cve"></reference>
          </references>
          <description>A flaw was found in Undertow. A buffer leak on the incoming WebSocket PONG message may lead to memory exhaustion. This flaw allows an attacker to cause a denial of service. The highest threat from this vulnerability is availability.(CVE-2021-3690)A flaw was found in Undertow. When an AJP request is sent that exceeds the max-header-size attribute in ajp-listener, JBoss EAP is marked in an error state by mod_cluster in httpd, causing JBoss EAP to close the TCP connection without returning an AJP response. This happens because mod_proxy_cluster marks the JBoss EAP instance as an error worker when the TCP connection is closed from the backend after sending the AJP request without receiving an AJP response, and stops forwarding. This issue could allow a malicious user could to repeatedly send requests that exceed the max-header-size, causing a Denial of Service (DoS).(CVE-2023-5379)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="noarch" name="undertow" release="7.oe2203sp4" version="1.4.0">
                         <filename>undertow-1.4.0-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="undertow-javadoc" release="7.oe2203sp4" version="1.4.0">
                         <filename>undertow-javadoc-1.4.0-7.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2359</id>
          <title>An update for ghostscript is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-11-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46951" id="CVE-2024-46951" title="CVE-2024-46951" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46952" id="CVE-2024-46952" title="CVE-2024-46952" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46955" id="CVE-2024-46955" title="CVE-2024-46955" type="cve"></reference>
          </references>
          <description>VUL-0: CVE-2024-46951: ghostscript: Arbitrary code execution via unchecked &#34;Implementation&#34; pointer in &#34;Pattern&#34; color space(CVE-2024-46951)VUL-0: CVE-2024-46952: ghostscript: Buffer overflow in PDF XRef stream(CVE-2024-46952)VUL-0: CVE-2024-46955: ghostscript: Out of bounds read when reading color in &#34;Indexed&#34; color space(CVE-2024-46955)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="ghostscript" release="17.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-9.55.0-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ghostscript-debuginfo" release="17.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-debuginfo-9.55.0-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ghostscript-debugsource" release="17.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-debugsource-9.55.0-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ghostscript-devel" release="17.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-devel-9.55.0-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ghostscript-tools-dvipdf" release="17.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-tools-dvipdf-9.55.0-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="ghostscript-help" release="17.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-help-9.55.0-17.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript" release="17.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-9.55.0-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript-debuginfo" release="17.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-debuginfo-9.55.0-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript-debugsource" release="17.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-debugsource-9.55.0-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript-devel" release="17.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-devel-9.55.0-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript-tools-dvipdf" release="17.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-tools-dvipdf-9.55.0-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2360</id>
          <title>An update for assimp is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-11-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-48425" id="CVE-2024-48425" title="CVE-2024-48425" type="cve"></reference>
          </references>
          <description>A segmentation fault (SEGV) was detected in the Assimp::SplitLargeMeshesProcess_Triangle::UpdateNode function within the Assimp library during fuzz testing using AddressSanitizer. The crash occurs due to a read access violation at address 0x000000000460, which points to the zero page, indicating a null or invalid pointer dereference.(CVE-2024-48425)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="assimp" release="4.oe2203sp4" version="5.2.4">
                         <filename>assimp-5.2.4-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="assimp-debuginfo" release="4.oe2203sp4" version="5.2.4">
                         <filename>assimp-debuginfo-5.2.4-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="assimp-debugsource" release="4.oe2203sp4" version="5.2.4">
                         <filename>assimp-debugsource-5.2.4-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="assimp-devel" release="4.oe2203sp4" version="5.2.4">
                         <filename>assimp-devel-5.2.4-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="assimp-help" release="4.oe2203sp4" version="5.2.4">
                         <filename>assimp-help-5.2.4-4.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-assimp" release="4.oe2203sp4" version="5.2.4">
                         <filename>python3-assimp-5.2.4-4.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="assimp" release="4.oe2203sp4" version="5.2.4">
                         <filename>assimp-5.2.4-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="assimp-debuginfo" release="4.oe2203sp4" version="5.2.4">
                         <filename>assimp-debuginfo-5.2.4-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="assimp-debugsource" release="4.oe2203sp4" version="5.2.4">
                         <filename>assimp-debugsource-5.2.4-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="assimp-devel" release="4.oe2203sp4" version="5.2.4">
                         <filename>assimp-devel-5.2.4-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2361</id>
          <title>An update for gsl is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2024-11-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50610" id="CVE-2024-50610" title="CVE-2024-50610" type="cve"></reference>
          </references>
          <description>GSL (GNU Scientific Library) through 2.8 has an integer signedness error in gsl_siman_solve_many in siman/siman.c. When params.n_tries is negative, incorrect memory allocation occurs.(CVE-2024-50610)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="gsl" release="12.oe2203sp4" version="2.4">
                         <filename>gsl-2.4-12.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gsl-debuginfo" release="12.oe2203sp4" version="2.4">
                         <filename>gsl-debuginfo-2.4-12.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gsl-debugsource" release="12.oe2203sp4" version="2.4">
                         <filename>gsl-debugsource-2.4-12.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gsl-devel" release="12.oe2203sp4" version="2.4">
                         <filename>gsl-devel-2.4-12.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="gsl-help" release="12.oe2203sp4" version="2.4">
                         <filename>gsl-help-2.4-12.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gsl" release="12.oe2203sp4" version="2.4">
                         <filename>gsl-2.4-12.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gsl-debuginfo" release="12.oe2203sp4" version="2.4">
                         <filename>gsl-debuginfo-2.4-12.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gsl-debugsource" release="12.oe2203sp4" version="2.4">
                         <filename>gsl-debugsource-2.4-12.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gsl-devel" release="12.oe2203sp4" version="2.4">
                         <filename>gsl-devel-2.4-12.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2362</id>
          <title>An update for jetty is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2024-11-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6762" id="CVE-2024-6762" title="CVE-2024-6762" type="cve"></reference>
          </references>
          <description>Jetty PushSessionCacheFilter can be exploited by unauthenticated users  to launch remote DoS attacks by exhausting the server’s memory.(CVE-2024-6762)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="jetty" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-alpn-client" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-alpn-client-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-alpn-server" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-alpn-server-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-annotations" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-annotations-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-ant" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-ant-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-cdi" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-cdi-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-client" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-client-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-continuation" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-continuation-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-deploy" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-deploy-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-fcgi-client" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-fcgi-client-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-fcgi-server" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-fcgi-server-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-http" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-http-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-http-spi" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-http-spi-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-http2-client" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-http2-client-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-http2-common" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-http2-common-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-http2-hpack" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-http2-hpack-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-http2-http-client-transport" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-http2-http-client-transport-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-http2-server" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-http2-server-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-httpservice" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-httpservice-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-infinispan" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-infinispan-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-io" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-io-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-jaas" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-jaas-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-jaspi" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-jaspi-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-javadoc" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-javadoc-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-javax-websocket-client-impl" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-javax-websocket-client-impl-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-javax-websocket-server-impl" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-javax-websocket-server-impl-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-jmx" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-jmx-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-jndi" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-jndi-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-jsp" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-jsp-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-jspc-maven-plugin" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-jspc-maven-plugin-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-jstl" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-jstl-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-maven-plugin" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-maven-plugin-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-nosql" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-nosql-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-osgi-alpn" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-osgi-alpn-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-osgi-boot" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-osgi-boot-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-osgi-boot-jsp" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-osgi-boot-jsp-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-osgi-boot-warurl" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-osgi-boot-warurl-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-plus" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-plus-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-project" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-project-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-proxy" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-proxy-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-quickstart" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-quickstart-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-rewrite" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-rewrite-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-security" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-security-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-server" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-server-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-servlet" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-servlet-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-servlets" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-servlets-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-spring" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-spring-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-start" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-start-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-unixsocket" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-unixsocket-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-util" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-util-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-util-ajax" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-util-ajax-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-webapp" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-webapp-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-websocket-api" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-websocket-api-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-websocket-client" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-websocket-client-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-websocket-common" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-websocket-common-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-websocket-server" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-websocket-server-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-websocket-servlet" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-websocket-servlet-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-xml" release="8.oe2203sp4" version="9.4.16">
                         <filename>jetty-xml-9.4.16-8.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2366</id>
          <title>An update for dcraw is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2024-11-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2017-13735" id="CVE-2017-13735" title="CVE-2017-13735" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2017-14608" id="CVE-2017-14608" title="CVE-2017-14608" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2018-19655" id="CVE-2018-19655" title="CVE-2018-19655" type="cve"></reference>
          </references>
          <description>(CVE-2017-13735)(CVE-2017-14608)A stack-based buffer overflow in the find_green() function of dcraw through 9.28, as used in ufraw-batch and many other products, may allow a remote attacker to cause a control-flow hijack, denial-of-service, or unspecified other impact via a maliciously crafted raw photo file.(CVE-2018-19655)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="dcraw" release="7.oe2203sp4" version="9.28.0">
                         <filename>dcraw-9.28.0-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="dcraw-debuginfo" release="7.oe2203sp4" version="9.28.0">
                         <filename>dcraw-debuginfo-9.28.0-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="dcraw-debugsource" release="7.oe2203sp4" version="9.28.0">
                         <filename>dcraw-debugsource-9.28.0-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="dcraw-help" release="7.oe2203sp4" version="9.28.0">
                         <filename>dcraw-help-9.28.0-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="dcraw" release="7.oe2203sp4" version="9.28.0">
                         <filename>dcraw-9.28.0-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="dcraw-debuginfo" release="7.oe2203sp4" version="9.28.0">
                         <filename>dcraw-debuginfo-9.28.0-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="dcraw-debugsource" release="7.oe2203sp4" version="9.28.0">
                         <filename>dcraw-debugsource-9.28.0-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2368</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-11-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48961" id="CVE-2022-48961" title="CVE-2022-48961" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48975" id="CVE-2022-48975" title="CVE-2022-48975" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49004" id="CVE-2022-49004" title="CVE-2022-49004" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45021" id="CVE-2024-45021" title="CVE-2024-45021" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46677" id="CVE-2024-46677" title="CVE-2024-46677" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46809" id="CVE-2024-46809" title="CVE-2024-46809" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47659" id="CVE-2024-47659" title="CVE-2024-47659" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47660" id="CVE-2024-47660" title="CVE-2024-47660" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47668" id="CVE-2024-47668" title="CVE-2024-47668" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47673" id="CVE-2024-47673" title="CVE-2024-47673" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47690" id="CVE-2024-47690" title="CVE-2024-47690" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47691" id="CVE-2024-47691" title="CVE-2024-47691" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47693" id="CVE-2024-47693" title="CVE-2024-47693" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47696" id="CVE-2024-47696" title="CVE-2024-47696" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47699" id="CVE-2024-47699" title="CVE-2024-47699" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47701" id="CVE-2024-47701" title="CVE-2024-47701" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47703" id="CVE-2024-47703" title="CVE-2024-47703" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47705" id="CVE-2024-47705" title="CVE-2024-47705" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47723" id="CVE-2024-47723" title="CVE-2024-47723" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47726" id="CVE-2024-47726" title="CVE-2024-47726" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47739" id="CVE-2024-47739" title="CVE-2024-47739" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47742" id="CVE-2024-47742" title="CVE-2024-47742" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47748" id="CVE-2024-47748" title="CVE-2024-47748" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47756" id="CVE-2024-47756" title="CVE-2024-47756" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49855" id="CVE-2024-49855" title="CVE-2024-49855" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49858" id="CVE-2024-49858" title="CVE-2024-49858" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49859" id="CVE-2024-49859" title="CVE-2024-49859" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49860" id="CVE-2024-49860" title="CVE-2024-49860" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49862" id="CVE-2024-49862" title="CVE-2024-49862" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49877" id="CVE-2024-49877" title="CVE-2024-49877" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49879" id="CVE-2024-49879" title="CVE-2024-49879" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49881" id="CVE-2024-49881" title="CVE-2024-49881" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49882" id="CVE-2024-49882" title="CVE-2024-49882" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49883" id="CVE-2024-49883" title="CVE-2024-49883" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49884" id="CVE-2024-49884" title="CVE-2024-49884" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49886" id="CVE-2024-49886" title="CVE-2024-49886" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49889" id="CVE-2024-49889" title="CVE-2024-49889" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49896" id="CVE-2024-49896" title="CVE-2024-49896" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49913" id="CVE-2024-49913" title="CVE-2024-49913" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49917" id="CVE-2024-49917" title="CVE-2024-49917" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49922" id="CVE-2024-49922" title="CVE-2024-49922" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49924" id="CVE-2024-49924" title="CVE-2024-49924" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49933" id="CVE-2024-49933" title="CVE-2024-49933" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49934" id="CVE-2024-49934" title="CVE-2024-49934" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49936" id="CVE-2024-49936" title="CVE-2024-49936" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49940" id="CVE-2024-49940" title="CVE-2024-49940" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49950" id="CVE-2024-49950" title="CVE-2024-49950" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49954" id="CVE-2024-49954" title="CVE-2024-49954" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49955" id="CVE-2024-49955" title="CVE-2024-49955" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49958" id="CVE-2024-49958" title="CVE-2024-49958" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49973" id="CVE-2024-49973" title="CVE-2024-49973" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49975" id="CVE-2024-49975" title="CVE-2024-49975" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49978" id="CVE-2024-49978" title="CVE-2024-49978" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49981" id="CVE-2024-49981" title="CVE-2024-49981" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49992" id="CVE-2024-49992" title="CVE-2024-49992" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49995" id="CVE-2024-49995" title="CVE-2024-49995" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49996" id="CVE-2024-49996" title="CVE-2024-49996" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50002" id="CVE-2024-50002" title="CVE-2024-50002" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50007" id="CVE-2024-50007" title="CVE-2024-50007" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50008" id="CVE-2024-50008" title="CVE-2024-50008" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50015" id="CVE-2024-50015" title="CVE-2024-50015" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50016" id="CVE-2024-50016" title="CVE-2024-50016" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50028" id="CVE-2024-50028" title="CVE-2024-50028" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50033" id="CVE-2024-50033" title="CVE-2024-50033" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50035" id="CVE-2024-50035" title="CVE-2024-50035" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50040" id="CVE-2024-50040" title="CVE-2024-50040" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50047" id="CVE-2024-50047" title="CVE-2024-50047" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50058" id="CVE-2024-50058" title="CVE-2024-50058" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50059" id="CVE-2024-50059" title="CVE-2024-50059" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50060" id="CVE-2024-50060" title="CVE-2024-50060" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50063" id="CVE-2024-50063" title="CVE-2024-50063" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50064" id="CVE-2024-50064" title="CVE-2024-50064" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50067" id="CVE-2024-50067" title="CVE-2024-50067" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50074" id="CVE-2024-50074" title="CVE-2024-50074" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50083" id="CVE-2024-50083" title="CVE-2024-50083" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:  net: mdio: fix unbalanced fwnode reference count in mdio_device_release()  There is warning report about of_node refcount leak while probing mdio device:  OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /spi/soc@0/mdio@710700c0/ethernet@4  In of_mdiobus_register_device(), we increase fwnode refcount by fwnode_handle_get() before associating the of_node with mdio device, but it has never been decreased in normal path. Since that, in mdio_device_release(), it needs to call fwnode_handle_put() in addition instead of calling kfree() directly.  After above, just calling mdio_device_free() in the error handle path of of_mdiobus_register_device() is enough to keep the refcount balanced.(CVE-2022-48961)In the Linux kernel, the following vulnerability has been resolved:  gpiolib: fix memory leak in gpiochip_setup_dev()  Here is a backtrace report about memory leak detected in gpiochip_setup_dev():  unreferenced object 0xffff88810b406400 (size 512):   comm &#34;python3&#34;, pid 1682, jiffies 4295346908 (age 24.090s)   backtrace:     kmalloc_trace     device_add  device_private_init at drivers/base/core.c:3361    (inlined by) device_add at drivers/base/core.c:3411     cdev_device_add     gpiolib_cdev_register     gpiochip_setup_dev     gpiochip_add_data_with_key  gcdev_register() &amp; gcdev_unregister() would call device_add() &amp; device_del() (no matter CONFIG_GPIO_CDEV is enabled or not) to register/unregister device.  However, if device_add() succeeds, some resource (like struct device_private allocated by device_private_init()) is not released by device_del().  Therefore, after device_add() succeeds by gcdev_register(), it needs to call put_device() to release resource in the error handle path.  Here we move forward the register of release function, and let it release every piece of resource by put_device() instead of kfree().  While at it, fix another subtle issue, i.e. when gc-&gt;ngpio is equal to 0, we still call kcalloc() and, in case of further error, kfree() on the ZERO_PTR pointer, which is not NULL. It&#39;s not a bug per se, but rather waste of the resources and potentially wrong expectation about contents of the gdev-&gt;descs variable.(CVE-2022-48975)In the Linux kernel, the following vulnerability has been resolved:  riscv: Sync efi page table&#39;s kernel mappings before switching  The EFI page table is initially created as a copy of the kernel page table. With VMAP_STACK enabled, kernel stacks are allocated in the vmalloc area: if the stack is allocated in a new PGD (one that was not present at the moment of the efi page table creation or not synced in a previous vmalloc fault), the kernel will take a trap when switching to the efi page table when the vmalloc kernel stack is accessed, resulting in a kernel panic.  Fix that by updating the efi kernel mappings before switching to the efi page table.(CVE-2022-49004)In the Linux kernel, the following vulnerability has been resolved:memcg_write_event_control(): fix a user-triggerable oopswe are *not* guaranteed that anything past the terminating NULis mapped (let alone initialized with anything sane).(CVE-2024-45021)In the Linux kernel, the following vulnerability has been resolved:gtp: fix a potential NULL pointer dereferenceWhen sockfd_lookup() fails, gtp_encap_enable_socket() returns aNULL pointer, but its callers only check for error pointers thus missthe NULL pointer case.Fix it by returning an error pointer with the error code carried fromsockfd_lookup().(I found this bug during code inspection.)(CVE-2024-46677)In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check BIOS images before it is usedBIOS images may fail to load and null checks are added before they areused.This fixes 6 NULL_RETURNS issues reported by Coverity.(CVE-2024-46809)In the Linux kernel, the following vulnerability has been resolved:smack: tcp: ipv4, fix incorrect labelingCurrently, Smack mirrors the label of incoming tcp/ipv4 connections:when a label &#39;foo&#39; connects to a label &#39;bar&#39; with tcp/ipv4,&#39;foo&#39; always gets &#39;foo&#39; in returned ipv4 packets. So,1) returned packets are incorrectly labeled (&#39;foo&#39; instead of &#39;bar&#39;)2) &#39;bar&#39; can write to &#39;foo&#39; without being authorized to write.Here is a scenario how to see this:* Take two machines, let&#39;s call them C and S,   with active Smack in the default state   (no settings, no rules, no labeled hosts, only builtin labels)* At S, add Smack rule &#39;foo bar w&#39;   (labels &#39;foo&#39; and &#39;bar&#39; are instantiated at S at this moment)* At S, at label &#39;bar&#39;, launch a program   that listens for incoming tcp/ipv4 connections* From C, at label &#39;foo&#39;, connect to the listener at S.   (label &#39;foo&#39; is instantiated at C at this moment)   Connection succeedes and works.* Send some data in both directions.* Collect network traffic of this connection.All packets in both directions are labeled with the CIPSOof the label &#39;foo&#39;. Hence, label &#39;bar&#39; writes to &#39;foo&#39; withoutbeing authorized, and even without ever being known at C.If anybody cares: exactly the same happens with DCCP.This behavior 1st manifested in release 2.6.29.4 (see Fixes below)and it looks unintentional. At least, no explanation was provided.I changed returned packes label into the &#39;bar&#39;,to bring it into line with the Smack documentation claims.(CVE-2024-47659)In the Linux kernel, the following vulnerability has been resolved:fsnotify: clear PARENT_WATCHED flags lazilyIn some setups directories can have many (usually negative) dentries.Hence __fsnotify_update_child_dentry_flags() function can take asignificant amount of time. Since the bulk of this function happensunder inode-&gt;i_lock this causes a significant contention on the lockwhen we remove the watch from the directory as the__fsnotify_update_child_dentry_flags() call from fsnotify_recalc_mask()races with __fsnotify_update_child_dentry_flags() calls from__fsnotify_parent() happening on children. This can lead upto softlockupreports reported by users.Fix the problem by calling fsnotify_update_children_dentry_flags() toset PARENT_WATCHED flags only when parent starts watching children.When parent stops watching children, clear false positive PARENT_WATCHEDflags lazily in __fsnotify_parent() for each accessed child.(CVE-2024-47660)In the Linux kernel, the following vulnerability has been resolved:lib/generic-radix-tree.c: Fix rare race in __genradix_ptr_alloc()If we need to increase the tree depth, allocate a new node, and thenrace with another thread that increased the tree depth before us, we&#39;llstill have a preallocated node that might be used later.If we then use that node for a new non-root node, it&#39;ll still have apointer to the old root instead of being zeroed - fix this by zeroing itin the cmpxchg failure path.(CVE-2024-47668)In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: mvm: pause TCM when the firmware is stoppedNot doing so will make us send a host command to the transport while thefirmware is not alive, which will trigger a WARNING.bad state = 0WARNING: CPU: 2 PID: 17434 at drivers/net/wireless/intel/iwlwifi/iwl-trans.c:115 iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi]RIP: 0010:iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi]Call Trace: &lt;TASK&gt; iwl_mvm_send_cmd+0x40/0xc0 [iwlmvm] iwl_mvm_config_scan+0x198/0x260 [iwlmvm] iwl_mvm_recalc_tcm+0x730/0x11d0 [iwlmvm] iwl_mvm_tcm_work+0x1d/0x30 [iwlmvm] process_one_work+0x29e/0x640 worker_thread+0x2df/0x690 ? rescuer_thread+0x540/0x540 kthread+0x192/0x1e0 ? set_kthread_struct+0x90/0x90 ret_from_fork+0x22/0x30(CVE-2024-47673)In the Linux kernel, the following vulnerability has been resolved:  f2fs: get rid of online repaire on corrupted directory  syzbot reports a f2fs bug as below:  kernel BUG at fs/f2fs/inode.c:896! RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896 Call Trace:  evict+0x532/0x950 fs/inode.c:704  dispose_list fs/inode.c:747 [inline]  evict_inodes+0x5f9/0x690 fs/inode.c:797  generic_shutdown_super+0x9d/0x2d0 fs/super.c:627  kill_block_super+0x44/0x90 fs/super.c:1696  kill_f2fs_super+0x344/0x690 fs/f2fs/super.c:4898  deactivate_locked_super+0xc4/0x130 fs/super.c:473  cleanup_mnt+0x41f/0x4b0 fs/namespace.c:1373  task_work_run+0x24f/0x310 kernel/task_work.c:228  ptrace_notify+0x2d2/0x380 kernel/signal.c:2402  ptrace_report_syscall include/linux/ptrace.h:415 [inline]  ptrace_report_syscall_exit include/linux/ptrace.h:477 [inline]  syscall_exit_work+0xc6/0x190 kernel/entry/common.c:173  syscall_exit_to_user_mode_prepare kernel/entry/common.c:200 [inline]  __syscall_exit_to_user_mode_work kernel/entry/common.c:205 [inline]  syscall_exit_to_user_mode+0x279/0x370 kernel/entry/common.c:218  do_syscall_64+0x100/0x230 arch/x86/entry/common.c:89  entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896  Online repaire on corrupted directory in f2fs_lookup() can generate dirty data/meta while racing w/ readonly remount, it may leave dirty inode after filesystem becomes readonly, however, checkpoint() will skips flushing dirty inode in a state of readonly mode, result in above panic.  Let&#39;s get rid of online repaire in f2fs_lookup(), and leave the work to fsck.f2fs.(CVE-2024-47690)In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread()  syzbot reports a f2fs bug as below:   __dump_stack lib/dump_stack.c:88 [inline]  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114  print_report+0xe8/0x550 mm/kasan/report.c:491  kasan_report+0x143/0x180 mm/kasan/report.c:601  kasan_check_range+0x282/0x290 mm/kasan/generic.c:189  instrument_atomic_read_write include/linux/instrumented.h:96 [inline]  atomic_fetch_add_relaxed include/linux/atomic/atomic-instrumented.h:252 [inline]  __refcount_add include/linux/refcount.h:184 [inline]  __refcount_inc include/linux/refcount.h:241 [inline]  refcount_inc include/linux/refcount.h:258 [inline]  get_task_struct include/linux/sched/task.h:118 [inline]  kthread_stop+0xca/0x630 kernel/kthread.c:704  f2fs_stop_gc_thread+0x65/0xb0 fs/f2fs/gc.c:210  f2fs_do_shutdown+0x192/0x540 fs/f2fs/file.c:2283  f2fs_ioc_shutdown fs/f2fs/file.c:2325 [inline]  __f2fs_ioctl+0x443a/0xbe60 fs/f2fs/file.c:4325  vfs_ioctl fs/ioctl.c:51 [inline]  __do_sys_ioctl fs/ioctl.c:907 [inline]  __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893  do_syscall_x64 arch/x86/entry/common.c:52 [inline]  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  The root cause is below race condition, it may cause use-after-free issue in sbi-&gt;gc_th pointer.  - remount  - f2fs_remount   - f2fs_stop_gc_thread    - kfree(gc_th)     - f2fs_ioc_shutdown      - f2fs_do_shutdown       - f2fs_stop_gc_thread        - kthread_stop(gc_th-&gt;f2fs_gc_task)    : sbi-&gt;gc_thread = NULL;  We will call f2fs_do_shutdown() in two paths: - for f2fs_ioc_shutdown() path, we should grab sb-&gt;s_umount semaphore for fixing. - for f2fs_shutdown() path, it&#39;s safe since caller has already grabbed sb-&gt;s_umount semaphore.(CVE-2024-47691)In the Linux kernel, the following vulnerability has been resolved:  IB/core: Fix ib_cache_setup_one error flow cleanup  When ib_cache_update return an error, we exit ib_cache_setup_one instantly with no proper cleanup, even though before this we had already successfully done gid_table_setup_one, that results in the kernel WARN below.  Do proper cleanup using gid_table_cleanup_one before returning the err in order to fix the issue.  WARNING: CPU: 4 PID: 922 at drivers/infiniband/core/cache.c:806 gid_table_release_one+0x181/0x1a0 Modules linked in: CPU: 4 UID: 0 PID: 922 Comm: c_repro Not tainted 6.11.0-rc1+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:gid_table_release_one+0x181/0x1a0 Code: 44 8b 38 75 0c e8 2f cb 34 ff 4d 8b b5 28 05 00 00 e8 23 cb 34 ff 44 89 f9 89 da 4c 89 f6 48 c7 c7 d0 58 14 83 e8 4f de 21 ff &lt;0f&gt; 0b 4c 8b 75 30 e9 54 ff ff ff 48 8    3 c4 10 5b 5d 41 5c 41 5d 41 RSP: 0018:ffffc90002b835b0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c8527 RDX: 0000000000000000 RSI: ffffffff811c8534 RDI: 0000000000000001 RBP: ffff8881011b3d00 R08: ffff88810b3abe00 R09: 205d303839303631 R10: 666572207972746e R11: 72746e6520444947 R12: 0000000000000001 R13: ffff888106390000 R14: ffff8881011f2110 R15: 0000000000000001 FS:  00007fecc3b70800(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000340 CR3: 000000010435a001 CR4: 00000000003706b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace:  &lt;TASK&gt;  ? show_regs+0x94/0xa0  ? __warn+0x9e/0x1c0  ? gid_table_release_one+0x181/0x1a0  ? report_bug+0x1f9/0x340  ? gid_table_release_one+0x181/0x1a0  ? handle_bug+0xa2/0x110  ? exc_invalid_op+0x31/0xa0  ? asm_exc_invalid_op+0x16/0x20  ? __warn_printk+0xc7/0x180  ? __warn_printk+0xd4/0x180  ? gid_table_release_one+0x181/0x1a0  ib_device_release+0x71/0xe0  ? __pfx_ib_device_release+0x10/0x10  device_release+0x44/0xd0  kobject_put+0x135/0x3d0  put_device+0x20/0x30  rxe_net_add+0x7d/0xa0  rxe_newlink+0xd7/0x190  nldev_newlink+0x1b0/0x2a0  ? __pfx_nldev_newlink+0x10/0x10  rdma_nl_rcv_msg+0x1ad/0x2e0  rdma_nl_rcv_skb.constprop.0+0x176/0x210  netlink_unicast+0x2de/0x400  netlink_sendmsg+0x306/0x660  __sock_sendmsg+0x110/0x120  ____sys_sendmsg+0x30e/0x390  ___sys_sendmsg+0x9b/0xf0  ? kstrtouint+0x6e/0xa0  ? kstrtouint_from_user+0x7c/0xb0  ? get_pid_task+0xb0/0xd0  ? proc_fail_nth_write+0x5b/0x140  ? __fget_light+0x9a/0x200  ? preempt_count_add+0x47/0xa0  __sys_sendmsg+0x61/0xd0  do_syscall_64+0x50/0x110  entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2024-47693)In the Linux kernel, the following vulnerability has been resolved:  RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency  In the commit aee2424246f9 (&#34;RDMA/iwcm: Fix a use-after-free related to destroying CM IDs&#34;), the function flush_workqueue is invoked to flush the work queue iwcm_wq.  But at that time, the work queue iwcm_wq was created via the function alloc_ordered_workqueue without the flag WQ_MEM_RECLAIM.  Because the current process is trying to flush the whole iwcm_wq, if iwcm_wq doesn&#39;t have the flag WQ_MEM_RECLAIM, verify that the current process is not reclaiming memory or running on a workqueue which doesn&#39;t have the flag WQ_MEM_RECLAIM as that can break forward-progress guarantee leading to a deadlock.  The call trace is as below:  [  125.350876][ T1430] Call Trace: [  125.356281][ T1430]  &lt;TASK&gt; [ 125.361285][ T1430] ? __warn (kernel/panic.c:693) [ 125.367640][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.375689][ T1430] ? report_bug (lib/bug.c:180 lib/bug.c:219) [ 125.382505][ T1430] ? handle_bug (arch/x86/kernel/traps.c:239) [ 125.388987][ T1430] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) [ 125.395831][ T1430] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621) [ 125.403125][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.410984][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.418764][ T1430] __flush_workqueue (kernel/workqueue.c:3970) [ 125.426021][ T1430] ? __pfx___might_resched (kernel/sched/core.c:10151) [ 125.433431][ T1430] ? destroy_cm_id (drivers/infiniband/core/iwcm.c:375) iw_cm [ 125.441209][ T1430] ? __pfx___flush_workqueue (kernel/workqueue.c:3910) [ 125.473900][ T1430] ? _raw_spin_lock_irqsave (arch/x86/include/asm/atomic.h:107 include/linux/atomic/atomic-arch-fallback.h:2170 include/linux/atomic/atomic-instrumented.h:1302 include/asm-generic/qspinlock.h:111 include/linux/spinlock.h:187 include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162) [ 125.473909][ T1430] ? __pfx__raw_spin_lock_irqsave (kernel/locking/spinlock.c:161) [ 125.482537][ T1430] _destroy_id (drivers/infiniband/core/cma.c:2044) rdma_cm [ 125.495072][ T1430] nvme_rdma_free_queue (drivers/nvme/host/rdma.c:656 drivers/nvme/host/rdma.c:650) nvme_rdma [ 125.505827][ T1430] nvme_rdma_reset_ctrl_work (drivers/nvme/host/rdma.c:2180) nvme_rdma [ 125.505831][ T1430] process_one_work (kernel/workqueue.c:3231) [ 125.515122][ T1430] worker_thread (kernel/workqueue.c:3306 kernel/workqueue.c:3393) [ 125.515127][ T1430] ? __pfx_worker_thread (kernel/workqueue.c:3339) [ 125.531837][ T1430] kthread (kernel/kthread.c:389) [ 125.539864][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.550628][ T1430] ret_from_fork (arch/x86/kernel/process.c:147) [ 125.558840][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.558844][ T1430] ret_from_fork_asm (arch/x86/entry/entry_64.S:257) [  125.566487][ T1430]  &lt;/TASK&gt; [  125.566488][ T1430] ---[ end trace 0000000000000000 ]---(CVE-2024-47696)In the Linux kernel, the following vulnerability has been resolved:  nilfs2: fix potential null-ptr-deref in nilfs_btree_insert()  Patch series &#34;nilfs2: fix potential issues with empty b-tree nodes&#34;.  This series addresses three potential issues with empty b-tree nodes that can occur with corrupted filesystem images, including one recently discovered by syzbot.   This patch (of 3):  If a b-tree is broken on the device, and the b-tree height is greater than 2 (the level of the root node is greater than 1) even if the number of child nodes of the b-tree root is 0, a NULL pointer dereference occurs in nilfs_btree_prepare_insert(), which is called from nilfs_btree_insert().  This is because, when the number of child nodes of the b-tree root is 0, nilfs_btree_do_lookup() does not set the block buffer head in any of path[x].bp_bh, leaving it as the initial value of NULL, but if the level of the b-tree root node is greater than 1, nilfs_btree_get_nonroot_node(), which accesses the buffer memory of path[x].bp_bh, is called.  Fix this issue by adding a check to nilfs_btree_root_broken(), which performs sanity checks when reading the root node from the device, to detect this inconsistency.  Thanks to Lizhi Xu for trying to solve the bug and clarifying the cause early on.(CVE-2024-47699)In the Linux kernel, the following vulnerability has been resolved:  ext4: avoid OOB when system.data xattr changes underneath the filesystem  When looking up for an entry in an inlined directory, if e_value_offs is changed underneath the filesystem by some change in the block device, it will lead to an out-of-bounds access that KASAN detects as an UAF.  EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none. loop0: detected capacity change from 2048 to 2047 ================================================================== BUG: KASAN: use-after-free in ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 Read of size 1 at addr ffff88803e91130f by task syz-executor269/5103  CPU: 0 UID: 0 PID: 5103 Comm: syz-executor269 Not tainted 6.11.0-rc4-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace:  &lt;TASK&gt;  __dump_stack lib/dump_stack.c:93 [inline]  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119  print_address_description mm/kasan/report.c:377 [inline]  print_report+0x169/0x550 mm/kasan/report.c:488  kasan_report+0x143/0x180 mm/kasan/report.c:601  ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500  ext4_find_inline_entry+0x4be/0x5e0 fs/ext4/inline.c:1697  __ext4_find_entry+0x2b4/0x1b30 fs/ext4/namei.c:1573  ext4_lookup_entry fs/ext4/namei.c:1727 [inline]  ext4_lookup+0x15f/0x750 fs/ext4/namei.c:1795  lookup_one_qstr_excl+0x11f/0x260 fs/namei.c:1633  filename_create+0x297/0x540 fs/namei.c:3980  do_symlinkat+0xf9/0x3a0 fs/namei.c:4587  __do_sys_symlinkat fs/namei.c:4610 [inline]  __se_sys_symlinkat fs/namei.c:4607 [inline]  __x64_sys_symlinkat+0x95/0xb0 fs/namei.c:4607  do_syscall_x64 arch/x86/entry/common.c:52 [inline]  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f3e73ced469 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 21 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff4d40c258 EFLAGS: 00000246 ORIG_RAX: 000000000000010a RAX: ffffffffffffffda RBX: 0032656c69662f2e RCX: 00007f3e73ced469 RDX: 0000000020000200 RSI: 00000000ffffff9c RDI: 00000000200001c0 RBP: 0000000000000000 R08: 00007fff4d40c290 R09: 00007fff4d40c290 R10: 0023706f6f6c2f76 R11: 0000000000000246 R12: 00007fff4d40c27c R13: 0000000000000003 R14: 431bde82d7b634db R15: 00007fff4d40c2b0  &lt;/TASK&gt;  Calling ext4_xattr_ibody_find right after reading the inode with ext4_get_inode_loc will lead to a check of the validity of the xattrs, avoiding this problem.(CVE-2024-47701)In the Linux kernel, the following vulnerability has been resolved:  bpf, lsm: Add check for BPF LSM return value  A bpf prog returning a positive number attached to file_alloc_security hook makes kernel panic.  This happens because file system can not filter out the positive number returned by the LSM prog using IS_ERR, and misinterprets this positive number as a file pointer.  Given that hook file_alloc_security never returned positive number before the introduction of BPF LSM, and other BPF LSM hooks may encounter similar issues, this patch adds LSM return value check in verifier, to ensure no unexpected value is returned.(CVE-2024-47703)In the Linux kernel, the following vulnerability has been resolved:  block: fix potential invalid pointer dereference in blk_add_partition  The blk_add_partition() function initially used a single if-condition (IS_ERR(part)) to check for errors when adding a partition. This was modified to handle the specific case of -ENXIO separately, allowing the function to proceed without logging the error in this case. However, this change unintentionally left a path where md_autodetect_dev() could be called without confirming that part is a valid pointer.  This commit separates the error handling logic by splitting the initial if-condition, improving code readability and handling specific error scenarios explicitly. The function now distinguishes the general error case from -ENXIO without altering the existing behavior of md_autodetect_dev() calls.(CVE-2024-47705)In the Linux kernel, the following vulnerability has been resolved:  jfs: fix out-of-bounds in dbNextAG() and diAlloc()  In dbNextAG() , there is no check for the case where bmp-&gt;db_numag is greater or same than MAXAG due to a polluted image, which causes an out-of-bounds. Therefore, a bounds check should be added in dbMount().  And in dbNextAG(), a check for the case where agpref is greater than bmp-&gt;db_numag should be added, so an out-of-bounds exception should be prevented.  Additionally, a check for the case where agno is greater or same than MAXAG should be added in diAlloc() to prevent out-of-bounds.(CVE-2024-47723)In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to wait dio completion  It should wait all existing dio write IOs before block removal, otherwise, previous direct write IO may overwrite data in the block which may be reused by other inode.(CVE-2024-47726)In the Linux kernel, the following vulnerability has been resolved:  padata: use integer wrap around to prevent deadlock on seq_nr overflow  When submitting more than 2^32 padata objects to padata_do_serial, the current sorting implementation incorrectly sorts padata objects with overflowed seq_nr, causing them to be placed before existing objects in the reorder list. This leads to a deadlock in the serialization process as padata_find_next cannot match padata-&gt;seq_nr and pd-&gt;processed because the padata instance with overflowed seq_nr will be selected next.  To fix this, we use an unsigned integer wrap around to correctly sort padata objects in scenarios with integer overflow.(CVE-2024-47739)In the Linux kernel, the following vulnerability has been resolved:  firmware_loader: Block path traversal  Most firmware names are hardcoded strings, or are constructed from fairly constrained format strings where the dynamic parts are just some hex numbers or such.  However, there are a couple codepaths in the kernel where firmware file names contain string components that are passed through from a device or semi-privileged userspace; the ones I could find (not counting interfaces that require root privileges) are:   - lpfc_sli4_request_firmware_update() seems to construct the firmware    filename from &#34;ModelName&#34;, a string that was previously parsed out of    some descriptor (&#34;Vital Product Data&#34;) in lpfc_fill_vpd()  - nfp_net_fw_find() seems to construct a firmware filename from a model    name coming from nfp_hwinfo_lookup(pf-&gt;hwinfo, &#34;nffw.partno&#34;), which I    think parses some descriptor that was read from the device.    (But this case likely isn&#39;t exploitable because the format string looks    like &#34;netronome/nic_%s&#34;, and there shouldn&#39;t be any *folders* starting    with &#34;netronome/nic_&#34;. The previous case was different because there,    the &#34;%s&#34; is *at the start* of the format string.)  - module_flash_fw_schedule() is reachable from the    ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as    GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is    enough to pass the privilege check), and takes a userspace-provided    firmware name.    (But I think to reach this case, you need to have CAP_NET_ADMIN over a    network namespace that a special kind of ethernet device is mapped into,    so I think this is not a viable attack path in practice.)  Fix it by rejecting any firmware names containing &#34;..&#34; path components.  For what it&#39;s worth, I went looking and haven&#39;t found any USB device drivers that use the firmware loader dangerously.(CVE-2024-47742)In the Linux kernel, the following vulnerability has been resolved:  vhost_vdpa: assign irq bypass producer token correctly  We used to call irq_bypass_unregister_producer() in vhost_vdpa_setup_vq_irq() which is problematic as we don&#39;t know if the token pointer is still valid or not.  Actually, we use the eventfd_ctx as the token so the life cycle of the token should be bound to the VHOST_SET_VRING_CALL instead of vhost_vdpa_setup_vq_irq() which could be called by set_status().  Fixing this by setting up irq bypass producer&#39;s token when handling VHOST_SET_VRING_CALL and un-registering the producer before calling vhost_vring_ioctl() to prevent a possible use after free as eventfd could have been released in vhost_vring_ioctl(). And such registering and unregistering will only be done if DRIVER_OK is set.(CVE-2024-47748)In the Linux kernel, the following vulnerability has been resolved:  PCI: keystone: Fix if-statement expression in ks_pcie_quirk()  This code accidentally uses &amp;&amp; where || was intended.  It potentially results in a NULL dereference.  Thus, fix the if-statement expression to use the correct condition.  [kwilczynski: commit log](CVE-2024-47756)In the Linux kernel, the following vulnerability has been resolved:  nbd: fix race between timeout and normal completion  If request timetout is handled by nbd_requeue_cmd(), normal completion has to be stopped for avoiding to complete this requeued request, other use-after-free can be triggered.  Fix the race by clearing NBD_CMD_INFLIGHT in nbd_requeue_cmd(), meantime make sure that cmd-&gt;lock is grabbed for clearing the flag and the requeue.(CVE-2024-49855)In the Linux kernel, the following vulnerability has been resolved:  efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption  The TPM event log table is a Linux specific construct, where the data produced by the GetEventLog() boot service is cached in memory, and passed on to the OS using an EFI configuration table.  The use of EFI_LOADER_DATA here results in the region being left unreserved in the E820 memory map constructed by the EFI stub, and this is the memory description that is passed on to the incoming kernel by kexec, which is therefore unaware that the region should be reserved.  Even though the utility of the TPM2 event log after a kexec is questionable, any corruption might send the parsing code off into the weeds and crash the kernel. So let&#39;s use EFI_ACPI_RECLAIM_MEMORY instead, which is always treated as reserved by the E820 conversion logic.(CVE-2024-49858)In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to check atomic_file in f2fs ioctl interfaces  Some f2fs ioctl interfaces like f2fs_ioc_set_pin_file(), f2fs_move_file_range(), and f2fs_defragment_range() missed to check atomic_write status, which may cause potential race issue, fix it.(CVE-2024-49859)In the Linux kernel, the following vulnerability has been resolved:  ACPI: sysfs: validate return type of _STR method  Only buffer objects are valid return values of _STR.  If something else is returned description_show() will access invalid memory.(CVE-2024-49860)In the Linux kernel, the following vulnerability has been resolved:  powercap: intel_rapl: Fix off by one in get_rpi()  The rp-&gt;priv-&gt;rpi array is either rpi_msr or rpi_tpmi which have NR_RAPL_PRIMITIVES number of elements.  Thus the &gt; needs to be &gt;= to prevent an off by one access.(CVE-2024-49862)In the Linux kernel, the following vulnerability has been resolved:  ocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodate  When doing cleanup, if flags without OCFS2_BH_READAHEAD, it may trigger NULL pointer dereference in the following ocfs2_set_buffer_uptodate() if bh is NULL.(CVE-2024-49877)In the Linux kernel, the following vulnerability has been resolved:  drm: omapdrm: Add missing check for alloc_ordered_workqueue  As it may return NULL pointer and cause NULL pointer dereference. Add check for the return value of alloc_ordered_workqueue.(CVE-2024-49879)In the Linux kernel, the following vulnerability has been resolved:  ext4: update orig_path in ext4_find_extent()  In ext4_find_extent(), if the path is not big enough, we free it and set *orig_path to NULL. But after reallocating and successfully initializing the path, we don&#39;t update *orig_path, in which case the caller gets a valid path but a NULL ppath, and this may cause a NULL pointer dereference or a path memory leak. For example:  ext4_split_extent   path = *ppath = 2000   ext4_find_extent     if (depth &gt; path[0].p_maxdepth)       kfree(path = 2000);       *orig_path = path = NULL;       path = kcalloc() = 3000   ext4_split_extent_at(*ppath = NULL)     path = *ppath;     ex = path[depth].p_ext;     // NULL pointer dereference!  ================================================================== BUG: kernel NULL pointer dereference, address: 0000000000000010 CPU: 6 UID: 0 PID: 576 Comm: fsstress Not tainted 6.11.0-rc2-dirty #847 RIP: 0010:ext4_split_extent_at+0x6d/0x560 Call Trace:  &lt;TASK&gt;  ext4_split_extent.isra.0+0xcb/0x1b0  ext4_ext_convert_to_initialized+0x168/0x6c0  ext4_ext_handle_unwritten_extents+0x325/0x4d0  ext4_ext_map_blocks+0x520/0xdb0  ext4_map_blocks+0x2b0/0x690  ext4_iomap_begin+0x20e/0x2c0 [...] ==================================================================  Therefore, *orig_path is updated when the extent lookup succeeds, so that the caller can safely use path or *ppath.(CVE-2024-49881)In the Linux kernel, the following vulnerability has been resolved:  ext4: fix double brelse() the buffer of the extents path  In ext4_ext_try_to_merge_up(), set path[1].p_bh to NULL after it has been released, otherwise it may be released twice. An example of what triggers this is as follows:    split2    map    split1 |--------|-------|--------|  ext4_ext_map_blocks  ext4_ext_handle_unwritten_extents   ext4_split_convert_extents    // path-&gt;p_depth == 0    ext4_split_extent      // 1. do split1      ext4_split_extent_at        |ext4_ext_insert_extent        |  ext4_ext_create_new_leaf        |    ext4_ext_grow_indepth        |      le16_add_cpu(&amp;neh-&gt;eh_depth, 1)        |    ext4_find_extent        |      // return -ENOMEM        |// get error and try zeroout        |path = ext4_find_extent        |  path-&gt;p_depth = 1        |ext4_ext_try_to_merge        |  ext4_ext_try_to_merge_up        |    path-&gt;p_depth = 0        |    brelse(path[1].p_bh)  ---&gt; not set to NULL here        |// zeroout success      // 2. update path      ext4_find_extent      // 3. do split2      ext4_split_extent_at        ext4_ext_insert_extent          ext4_ext_create_new_leaf            ext4_ext_grow_indepth              le16_add_cpu(&amp;neh-&gt;eh_depth, 1)            ext4_find_extent              path[0].p_bh = NULL;              path-&gt;p_depth = 1              read_extent_tree_block  ---&gt; return err              // path[1].p_bh is still the old value              ext4_free_ext_path                ext4_ext_drop_refs                  // path-&gt;p_depth == 1                  brelse(path[1].p_bh)  ---&gt; brelse a buffer twice  Finally got the following WARRNING when removing the buffer from lru:  ============================================ VFS: brelse: Trying to free free buffer WARNING: CPU: 2 PID: 72 at fs/buffer.c:1241 __brelse+0x58/0x90 CPU: 2 PID: 72 Comm: kworker/u19:1 Not tainted 6.9.0-dirty #716 RIP: 0010:__brelse+0x58/0x90 Call Trace:  &lt;TASK&gt;  __find_get_block+0x6e7/0x810  bdev_getblk+0x2b/0x480  __ext4_get_inode_loc+0x48a/0x1240  ext4_get_inode_loc+0xb2/0x150  ext4_reserve_inode_write+0xb7/0x230  __ext4_mark_inode_dirty+0x144/0x6a0  ext4_ext_insert_extent+0x9c8/0x3230  ext4_ext_map_blocks+0xf45/0x2dc0  ext4_map_blocks+0x724/0x1700  ext4_do_writepages+0x12d6/0x2a70 [...] ============================================(CVE-2024-49882)In the Linux kernel, the following vulnerability has been resolved:  ext4: aovid use-after-free in ext4_ext_insert_extent()  As Ojaswin mentioned in Link, in ext4_ext_insert_extent(), if the path is reallocated in ext4_ext_create_new_leaf(), we&#39;ll use the stale path and cause UAF. Below is a sample trace with dummy values:  ext4_ext_insert_extent   path = *ppath = 2000   ext4_ext_create_new_leaf(ppath)     ext4_find_extent(ppath)       path = *ppath = 2000       if (depth &gt; path[0].p_maxdepth)             kfree(path = 2000);             *ppath = path = NULL;       path = kcalloc() = 3000       *ppath = 3000;       return path;   /* here path is still 2000, UAF! */   eh = path[depth].p_hdr  ================================================================== BUG: KASAN: slab-use-after-free in ext4_ext_insert_extent+0x26d4/0x3330 Read of size 8 at addr ffff8881027bf7d0 by task kworker/u36:1/179 CPU: 3 UID: 0 PID: 179 Comm: kworker/u6:1 Not tainted 6.11.0-rc2-dirty #866 Call Trace:  &lt;TASK&gt;  ext4_ext_insert_extent+0x26d4/0x3330  ext4_ext_map_blocks+0xe22/0x2d40  ext4_map_blocks+0x71e/0x1700  ext4_do_writepages+0x1290/0x2800 [...]  Allocated by task 179:  ext4_find_extent+0x81c/0x1f70  ext4_ext_map_blocks+0x146/0x2d40  ext4_map_blocks+0x71e/0x1700  ext4_do_writepages+0x1290/0x2800  ext4_writepages+0x26d/0x4e0  do_writepages+0x175/0x700 [...]  Freed by task 179:  kfree+0xcb/0x240  ext4_find_extent+0x7c0/0x1f70  ext4_ext_insert_extent+0xa26/0x3330  ext4_ext_map_blocks+0xe22/0x2d40  ext4_map_blocks+0x71e/0x1700  ext4_do_writepages+0x1290/0x2800  ext4_writepages+0x26d/0x4e0  do_writepages+0x175/0x700 [...] ==================================================================  So use *ppath to update the path to avoid the above problem.(CVE-2024-49883)In the Linux kernel, the following vulnerability has been resolved:  ext4: fix slab-use-after-free in ext4_split_extent_at()  We hit the following use-after-free:  ================================================================== BUG: KASAN: slab-use-after-free in ext4_split_extent_at+0xba8/0xcc0 Read of size 2 at addr ffff88810548ed08 by task kworker/u20:0/40 CPU: 0 PID: 40 Comm: kworker/u20:0 Not tainted 6.9.0-dirty #724 Call Trace:  &lt;TASK&gt;  kasan_report+0x93/0xc0  ext4_split_extent_at+0xba8/0xcc0  ext4_split_extent.isra.0+0x18f/0x500  ext4_split_convert_extents+0x275/0x750  ext4_ext_handle_unwritten_extents+0x73e/0x1580  ext4_ext_map_blocks+0xe20/0x2dc0  ext4_map_blocks+0x724/0x1700  ext4_do_writepages+0x12d6/0x2a70 [...]  Allocated by task 40:  __kmalloc_noprof+0x1ac/0x480  ext4_find_extent+0xf3b/0x1e70  ext4_ext_map_blocks+0x188/0x2dc0  ext4_map_blocks+0x724/0x1700  ext4_do_writepages+0x12d6/0x2a70 [...]  Freed by task 40:  kfree+0xf1/0x2b0  ext4_find_extent+0xa71/0x1e70  ext4_ext_insert_extent+0xa22/0x3260  ext4_split_extent_at+0x3ef/0xcc0  ext4_split_extent.isra.0+0x18f/0x500  ext4_split_convert_extents+0x275/0x750  ext4_ext_handle_unwritten_extents+0x73e/0x1580  ext4_ext_map_blocks+0xe20/0x2dc0  ext4_map_blocks+0x724/0x1700  ext4_do_writepages+0x12d6/0x2a70 [...] ==================================================================  The flow of issue triggering is as follows:  ext4_split_extent_at   path = *ppath   ext4_ext_insert_extent(ppath)     ext4_ext_create_new_leaf(ppath)       ext4_find_extent(orig_path)         path = *orig_path         read_extent_tree_block           // return -ENOMEM or -EIO         ext4_free_ext_path(path)           kfree(path)         *orig_path = NULL   a. If err is -ENOMEM:   ext4_ext_dirty(path + path-&gt;p_depth)   // path use-after-free !!!   b. If err is -EIO and we have EXT_DEBUG defined:   ext4_ext_show_leaf(path)     eh = path[depth].p_hdr     // path also use-after-free !!!  So when trying to zeroout or fix the extent length, call ext4_find_extent() to update the path.  In addition we use *ppath directly as an ext4_ext_show_leaf() input to avoid possible use-after-free when EXT_DEBUG is defined, and to avoid unnecessary path updates.(CVE-2024-49884)In the Linux kernel, the following vulnerability has been resolved:  platform/x86: ISST: Fix the KASAN report slab-out-of-bounds bug  Attaching SST PCI device to VM causes &#34;BUG: KASAN: slab-out-of-bounds&#34;. kasan report: [   19.411889] ================================================================== [   19.413702] BUG: KASAN: slab-out-of-bounds in _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [   19.415634] Read of size 8 at addr ffff888829e65200 by task cpuhp/16/113 [   19.417368] [   19.418627] CPU: 16 PID: 113 Comm: cpuhp/16 Tainted: G            E      6.9.0 #10 [   19.420435] Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.20192059.B64.2207280713 07/28/2022 [   19.422687] Call Trace: [   19.424091]  &lt;TASK&gt; [   19.425448]  dump_stack_lvl+0x5d/0x80 [   19.426963]  ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [   19.428694]  print_report+0x19d/0x52e [   19.430206]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [   19.431837]  ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [   19.433539]  kasan_report+0xf0/0x170 [   19.435019]  ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [   19.436709]  _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [   19.438379]  ? __pfx_sched_clock_cpu+0x10/0x10 [   19.439910]  isst_if_cpu_online+0x406/0x58f [isst_if_common] [   19.441573]  ? __pfx_isst_if_cpu_online+0x10/0x10 [isst_if_common] [   19.443263]  ? ttwu_queue_wakelist+0x2c1/0x360 [   19.444797]  cpuhp_invoke_callback+0x221/0xec0 [   19.446337]  cpuhp_thread_fun+0x21b/0x610 [   19.447814]  ? __pfx_cpuhp_thread_fun+0x10/0x10 [   19.449354]  smpboot_thread_fn+0x2e7/0x6e0 [   19.450859]  ? __pfx_smpboot_thread_fn+0x10/0x10 [   19.452405]  kthread+0x29c/0x350 [   19.453817]  ? __pfx_kthread+0x10/0x10 [   19.455253]  ret_from_fork+0x31/0x70 [   19.456685]  ? __pfx_kthread+0x10/0x10 [   19.458114]  ret_from_fork_asm+0x1a/0x30 [   19.459573]  &lt;/TASK&gt; [   19.460853] [   19.462055] Allocated by task 1198: [   19.463410]  kasan_save_stack+0x30/0x50 [   19.464788]  kasan_save_track+0x14/0x30 [   19.466139]  __kasan_kmalloc+0xaa/0xb0 [   19.467465]  __kmalloc+0x1cd/0x470 [   19.468748]  isst_if_cdev_register+0x1da/0x350 [isst_if_common] [   19.470233]  isst_if_mbox_init+0x108/0xff0 [isst_if_mbox_msr] [   19.471670]  do_one_initcall+0xa4/0x380 [   19.472903]  do_init_module+0x238/0x760 [   19.474105]  load_module+0x5239/0x6f00 [   19.475285]  init_module_from_file+0xd1/0x130 [   19.476506]  idempotent_init_module+0x23b/0x650 [   19.477725]  __x64_sys_finit_module+0xbe/0x130 [   19.476506]  idempotent_init_module+0x23b/0x650 [   19.477725]  __x64_sys_finit_module+0xbe/0x130 [   19.478920]  do_syscall_64+0x82/0x160 [   19.480036]  entry_SYSCALL_64_after_hwframe+0x76/0x7e [   19.481292] [   19.482205] The buggy address belongs to the object at ffff888829e65000  which belongs to the cache kmalloc-512 of size 512 [   19.484818] The buggy address is located 0 bytes to the right of  allocated 512-byte region [ffff888829e65000, ffff888829e65200) [   19.487447] [   19.488328] The buggy address belongs to the physical page: [   19.489569] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888829e60c00 pfn:0x829e60 [   19.491140] head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0 [   19.492466] anon flags: 0x57ffffc0000840(slab|head|node=1|zone=2|lastcpupid=0x1fffff) [   19.493914] page_type: 0xffffffff() [   19.494988] raw: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [   19.496451] raw: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [   19.497906] head: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [   19.499379] head: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [   19.500844] head: 0057ffffc0000003 ffffea0020a79801 ffffea0020a79848 00000000ffffffff [   19.502316] head: 0000000800000000 0000000000000000 00000000ffffffff 0000000000000000 [   19.503784] page dumped because: k ---truncated---(CVE-2024-49886)In the Linux kernel, the following vulnerability has been resolved:  ext4: avoid use-after-free in ext4_ext_show_leaf()  In ext4_find_extent(), path may be freed by error or be reallocated, so using a previously saved *ppath may have been freed and thus may trigger use-after-free, as follows:  ext4_split_extent   path = *ppath;   ext4_split_extent_at(ppath)   path = ext4_find_extent(ppath)   ext4_split_extent_at(ppath)     // ext4_find_extent fails to free path     // but zeroout succeeds   ext4_ext_show_leaf(inode, path)     eh = path[depth].p_hdr     // path use-after-free !!!  Similar to ext4_split_extent_at(), we use *ppath directly as an input to ext4_ext_show_leaf(). Fix a spelling error by the way.  Same problem in ext4_ext_handle_unwritten_extents(). Since &#39;path&#39; is only used in ext4_ext_show_leaf(), remove &#39;path&#39; and use *ppath directly.  This issue is triggered only when EXT_DEBUG is defined and therefore does not affect functionality.(CVE-2024-49889)In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Check stream before comparing them  [WHAT &amp; HOW] amdgpu_dm can pass a null stream to dc_is_stream_unchanged. It is necessary to check for null before dereferencing them.  This fixes 1 FORWARD_NULL issue reported by Coverity.(CVE-2024-49896)In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Add null check for top_pipe_to_program in commit_planes_for_stream  This commit addresses a null pointer dereference issue in the `commit_planes_for_stream` function at line 4140. The issue could occur when `top_pipe_to_program` is null.  The fix adds a check to ensure `top_pipe_to_program` is not null before accessing its stream_res. This prevents a null pointer dereference.  Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:4140 commit_planes_for_stream() error: we previously assumed &#39;top_pipe_to_program&#39; could be null (see line 3906)(CVE-2024-49913)In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Add NULL check for clk_mgr and clk_mgr-&gt;funcs in dcn30_init_hw  This commit addresses a potential null pointer dereference issue in the `dcn30_init_hw` function. The issue could occur when `dc-&gt;clk_mgr` or `dc-&gt;clk_mgr-&gt;funcs` is null.  The fix adds a check to ensure `dc-&gt;clk_mgr` and `dc-&gt;clk_mgr-&gt;funcs` is not null before accessing its functions. This prevents a potential null pointer dereference.  Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:789 dcn30_init_hw() error: we previously assumed &#39;dc-&gt;clk_mgr&#39; could be null (see line 628)(CVE-2024-49917)In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Check null pointers before using them  [WHAT &amp; HOW] These pointers are null checked previously in the same function, indicating they might be null as reported by Coverity. As a result, they need to be checked when used again.  This fixes 3 FORWARD_NULL issue reported by Coverity.(CVE-2024-49922)In the Linux kernel, the following vulnerability has been resolved:  fbdev: pxafb: Fix possible use after free in pxafb_task()  In the pxafb_probe function, it calls the pxafb_init_fbinfo function, after which &amp;fbi-&gt;task is associated with pxafb_task. Moreover, within this pxafb_init_fbinfo function, the pxafb_blank function within the &amp;pxafb_ops struct is capable of scheduling work.  If we remove the module which will call pxafb_remove to make cleanup, it will call unregister_framebuffer function which can call do_unregister_framebuffer to free fbi-&gt;fb through put_fb_info(fb_info), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows:  CPU0                                                CPU1                                     | pxafb_task pxafb_remove                       | unregister_framebuffer(info)       | do_unregister_framebuffer(fb_info) | put_fb_info(fb_info)               | // free fbi-&gt;fb                    | set_ctrlr_state(fbi, state)                                    | __pxafb_lcd_power(fbi, 0)                                    | fbi-&gt;lcd_power(on, &amp;fbi-&gt;fb.var)                                    | //use fbi-&gt;fb  Fix it by ensuring that the work is canceled before proceeding with the cleanup in pxafb_remove.  Note that only root user can remove the driver at runtime.(CVE-2024-49924)In the Linux kernel, the following vulnerability has been resolved:  blk_iocost: fix more out of bound shifts  Recently running UBSAN caught few out of bound shifts in the ioc_forgive_debts() function:  UBSAN: shift-out-of-bounds in block/blk-iocost.c:2142:38 shift exponent 80 is too large for 64-bit type &#39;u64&#39; (aka &#39;unsigned long long&#39;) ... UBSAN: shift-out-of-bounds in block/blk-iocost.c:2144:30 shift exponent 80 is too large for 64-bit type &#39;u64&#39; (aka &#39;unsigned long long&#39;) ... Call Trace: &lt;IRQ&gt; dump_stack_lvl+0xca/0x130 __ubsan_handle_shift_out_of_bounds+0x22c/0x280 ? __lock_acquire+0x6441/0x7c10 ioc_timer_fn+0x6cec/0x7750 ? blk_iocost_init+0x720/0x720 ? call_timer_fn+0x5d/0x470 call_timer_fn+0xfa/0x470 ? blk_iocost_init+0x720/0x720 __run_timer_base+0x519/0x700 ...  Actual impact of this issue was not identified but I propose to fix the undefined behaviour. The proposed fix to prevent those out of bound shifts consist of precalculating exponent before using it the shift operations by taking min value from the actual exponent and maximum possible number of bits.(CVE-2024-49933)In the Linux kernel, the following vulnerability has been resolved:  fs/inode: Prevent dump_mapping() accessing invalid dentry.d_name.name  It&#39;s observed that a crash occurs during hot-remove a memory device, in which user is accessing the hugetlb. See calltrace as following:  ------------[ cut here ]------------ WARNING: CPU: 1 PID: 14045 at arch/x86/mm/fault.c:1278 do_user_addr_fault+0x2a0/0x790 Modules linked in: kmem device_dax cxl_mem cxl_pmem cxl_port cxl_pci dax_hmem dax_pmem nd_pmem cxl_acpi nd_btt cxl_core crc32c_intel nvme virtiofs fuse nvme_core nfit libnvdimm dm_multipath scsi_dh_rdac scsi_dh_emc s mirror dm_region_hash dm_log dm_mod CPU: 1 PID: 14045 Comm: daxctl Not tainted 6.10.0-rc2-lizhijian+ #492 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:do_user_addr_fault+0x2a0/0x790 Code: 48 8b 00 a8 04 0f 84 b5 fe ff ff e9 1c ff ff ff 4c 89 e9 4c 89 e2 be 01 00 00 00 bf 02 00 00 00 e8 b5 ef 24 00 e9 42 fe ff ff &lt;0f&gt; 0b 48 83 c4 08 4c 89 ea 48 89 ee 4c 89 e7 5b 5d 41 5c 41 5d 41 RSP: 0000:ffffc90000a575f0 EFLAGS: 00010046 RAX: ffff88800c303600 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000001000 RSI: ffffffff82504162 RDI: ffffffff824b2c36 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffc90000a57658 R13: 0000000000001000 R14: ffff88800bc2e040 R15: 0000000000000000 FS:  00007f51cb57d880(0000) GS:ffff88807fd00000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000001000 CR3: 00000000072e2004 CR4: 00000000001706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace:  &lt;TASK&gt;  ? __warn+0x8d/0x190  ? do_user_addr_fault+0x2a0/0x790  ? report_bug+0x1c3/0x1d0  ? handle_bug+0x3c/0x70  ? exc_invalid_op+0x14/0x70  ? asm_exc_invalid_op+0x16/0x20  ? do_user_addr_fault+0x2a0/0x790  ? exc_page_fault+0x31/0x200  exc_page_fault+0x68/0x200 &lt;...snip...&gt; BUG: unable to handle page fault for address: 0000000000001000  #PF: supervisor read access in kernel mode  #PF: error_code(0x0000) - not-present page  PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0  Oops: Oops: 0000 [#1] PREEMPT SMP PTI  ---[ end trace 0000000000000000 ]---  BUG: unable to handle page fault for address: 0000000000001000  #PF: supervisor read access in kernel mode  #PF: error_code(0x0000) - not-present page  PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0  Oops: Oops: 0000 [#1] PREEMPT SMP PTI  CPU: 1 PID: 14045 Comm: daxctl Kdump: loaded Tainted: G        W          6.10.0-rc2-lizhijian+ #492  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014  RIP: 0010:dentry_name+0x1f4/0x440 &lt;...snip...&gt; ? dentry_name+0x2fa/0x440 vsnprintf+0x1f3/0x4f0 vprintk_store+0x23a/0x540 vprintk_emit+0x6d/0x330 _printk+0x58/0x80 dump_mapping+0x10b/0x1a0 ? __pfx_free_object_rcu+0x10/0x10 __dump_page+0x26b/0x3e0 ? vprintk_emit+0xe0/0x330 ? _printk+0x58/0x80 ? dump_page+0x17/0x50 dump_page+0x17/0x50 do_migrate_range+0x2f7/0x7f0 ? do_migrate_range+0x42/0x7f0 ? offline_pages+0x2f4/0x8c0 offline_pages+0x60a/0x8c0 memory_subsys_offline+0x9f/0x1c0 ? lockdep_hardirqs_on+0x77/0x100 ? _raw_spin_unlock_irqrestore+0x38/0x60 device_offline+0xe3/0x110 state_store+0x6e/0xc0 kernfs_fop_write_iter+0x143/0x200 vfs_write+0x39f/0x560 ksys_write+0x65/0xf0 do_syscall_64+0x62/0x130  Previously, some sanity check have been done in dump_mapping() before the print facility parsing &#39;%pd&#39; though, it&#39;s still possible to run into an invalid dentry.d_name.name.  Since dump_mapping() only needs to dump the filename only, retrieve it by itself in a safer way to prevent an unnecessary crash.  Note that either retrieving the filename with &#39;%pd&#39; or strncpy_from_kernel_nofault(), the filename could be unreliable.(CVE-2024-49934)In the Linux kernel, the following vulnerability has been resolved:  net/xen-netback: prevent UAF in xenvif_flush_hash()  During the list_for_each_entry_rcu iteration call of xenvif_flush_hash, kfree_rcu does not exist inside the rcu read critical section, so if kfree_rcu is called when the rcu grace period ends during the iteration, UAF occurs when accessing head-&gt;next after the entry becomes free.  Therefore, to solve this, you need to change it to list_for_each_entry_safe.(CVE-2024-49936)In the Linux kernel, the following vulnerability has been resolved:  l2tp: prevent possible tunnel refcount underflow  When a session is created, it sets a backpointer to its tunnel. When the session refcount drops to 0, l2tp_session_free drops the tunnel refcount if session-&gt;tunnel is non-NULL. However, session-&gt;tunnel is set in l2tp_session_create, before the tunnel refcount is incremented by l2tp_session_register, which leaves a small window where session-&gt;tunnel is non-NULL when the tunnel refcount hasn&#39;t been bumped.  Moving the assignment to l2tp_session_register is trivial but l2tp_session_create calls l2tp_session_set_header_len which uses session-&gt;tunnel to get the tunnel&#39;s encap. Add an encap arg to l2tp_session_set_header_len to avoid using session-&gt;tunnel.  If l2tpv3 sessions have colliding IDs, it is possible for l2tp_v3_session_get to race with l2tp_session_register and fetch a session which doesn&#39;t yet have session-&gt;tunnel set. Add a check for this case.(CVE-2024-49940)In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: L2CAP: Fix uaf in l2cap_connect  [Syzbot reported] BUG: KASAN: slab-use-after-free in l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 Read of size 8 at addr ffff8880241e9800 by task kworker/u9:0/54  CPU: 0 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-00268-g788220eee30d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Workqueue: hci2 hci_rx_work Call Trace:  &lt;TASK&gt;  __dump_stack lib/dump_stack.c:93 [inline]  dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:119  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  l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949  l2cap_connect_req net/bluetooth/l2cap_core.c:4080 [inline]  l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:4772 [inline]  l2cap_sig_channel net/bluetooth/l2cap_core.c:5543 [inline]  l2cap_recv_frame+0xf0b/0x8eb0 net/bluetooth/l2cap_core.c:6825  l2cap_recv_acldata+0x9b4/0xb70 net/bluetooth/l2cap_core.c:7514  hci_acldata_packet net/bluetooth/hci_core.c:3791 [inline]  hci_rx_work+0xaab/0x1610 net/bluetooth/hci_core.c:4028  process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231  process_scheduled_works kernel/workqueue.c:3312 [inline]  worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389  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 ...  Freed by task 5245:  kasan_save_stack+0x33/0x60 mm/kasan/common.c:47  kasan_save_track+0x14/0x30 mm/kasan/common.c:68  kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:579  poison_slab_object+0xf7/0x160 mm/kasan/common.c:240  __kasan_slab_free+0x32/0x50 mm/kasan/common.c:256  kasan_slab_free include/linux/kasan.h:184 [inline]  slab_free_hook mm/slub.c:2256 [inline]  slab_free mm/slub.c:4477 [inline]  kfree+0x12a/0x3b0 mm/slub.c:4598  l2cap_conn_free net/bluetooth/l2cap_core.c:1810 [inline]  kref_put include/linux/kref.h:65 [inline]  l2cap_conn_put net/bluetooth/l2cap_core.c:1822 [inline]  l2cap_conn_del+0x59d/0x730 net/bluetooth/l2cap_core.c:1802  l2cap_connect_cfm+0x9e6/0xf80 net/bluetooth/l2cap_core.c:7241  hci_connect_cfm include/net/bluetooth/hci_core.h:1960 [inline]  hci_conn_failed+0x1c3/0x370 net/bluetooth/hci_conn.c:1265  hci_abort_conn_sync+0x75a/0xb50 net/bluetooth/hci_sync.c:5583  abort_conn_sync+0x197/0x360 net/bluetooth/hci_conn.c:2917  hci_cmd_sync_work+0x1a4/0x410 net/bluetooth/hci_sync.c:328  process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231  process_scheduled_works kernel/workqueue.c:3312 [inline]  worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389  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-49950)In the Linux kernel, the following vulnerability has been resolved:  static_call: Replace pointless WARN_ON() in static_call_module_notify()  static_call_module_notify() triggers a WARN_ON(), when memory allocation fails in __static_call_add_module().  That&#39;s not really justified, because the failure case must be correctly handled by the well known call chain and the error code is passed through to the initiating userspace application.  A memory allocation fail is not a fatal problem, but the WARN_ON() takes the machine out when panic_on_warn is set.  Replace it with a pr_warn().(CVE-2024-49954)In the Linux kernel, the following vulnerability has been resolved:  ACPI: battery: Fix possible crash when unregistering a battery hook  When a battery hook returns an error when adding a new battery, then the battery hook is automatically unregistered. However the battery hook provider cannot know that, so it will later call battery_hook_unregister() on the already unregistered battery hook, resulting in a crash.  Fix this by using the list head to mark already unregistered battery hooks as already being unregistered so that they can be ignored by battery_hook_unregister().(CVE-2024-49955)In the Linux kernel, the following vulnerability has been resolved:  ocfs2: reserve space for inline xattr before attaching reflink tree  One of our customers reported a crash and a corrupted ocfs2 filesystem.  The crash was due to the detection of corruption.  Upon troubleshooting, the fsck -fn output showed the below corruption  [EXTENT_LIST_FREE] Extent list in owner 33080590 claims 230 as the next free chain record, but fsck believes the largest valid value is 227.  Clamp the next record value? n  The stat output from the debugfs.ocfs2 showed the following corruption where the &#34;Next Free Rec:&#34; had overshot the &#34;Count:&#34; in the root metadata block.          Inode: 33080590   Mode: 0640   Generation: 2619713622 (0x9c25a856)         FS Generation: 904309833 (0x35e6ac49)         CRC32: 00000000   ECC: 0000         Type: Regular   Attr: 0x0   Flags: Valid         Dynamic Features: (0x16) HasXattr InlineXattr Refcounted         Extended Attributes Block: 0  Extended Attributes Inline Size: 256         User: 0 (root)   Group: 0 (root)   Size: 281320357888         Links: 1   Clusters: 141738         ctime: 0x66911b56 0x316edcb8 -- Fri Jul 12 06:02:30.829349048 2024         atime: 0x66911d6b 0x7f7a28d -- Fri Jul 12 06:11:23.133669517 2024         mtime: 0x66911b56 0x12ed75d7 -- Fri Jul 12 06:02:30.317552087 2024         dtime: 0x0 -- Wed Dec 31 17:00:00 1969         Refcount Block: 2777346         Last Extblk: 2886943   Orphan Slot: 0         Sub Alloc Slot: 0   Sub Alloc Bit: 14         Tree Depth: 1   Count: 227   Next Free Rec: 230         ## Offset        Clusters       Block#         0  0             2310           2776351         1  2310          2139           2777375         2  4449          1221           2778399         3  5670          731            2779423         4  6401          566            2780447         .......          ....           .......         .......          ....           .......  The issue was in the reflink workfow while reserving space for inline xattr.  The problematic function is ocfs2_reflink_xattr_inline().  By the time this function is called the reflink tree is already recreated at the destination inode from the source inode.  At this point, this function reserves space for inline xattrs at the destination inode without even checking if there is space at the root metadata block.  It simply reduces the l_count from 243 to 227 thereby making space of 256 bytes for inline xattr whereas the inode already has extents beyond this index (in this case up to 230), thereby causing corruption.  The fix for this is to reserve space for inline metadata at the destination inode before the reflink tree gets recreated. The customer has verified the fix.(CVE-2024-49958)In the Linux kernel, the following vulnerability has been resolved:  r8169: add tally counter fields added with RTL8125  RTL8125 added fields to the tally counter, what may result in the chip dma&#39;ing these new fields to unallocated memory. Therefore make sure that the allocated memory area is big enough to hold all of the tally counter values, even if we use only parts of it.(CVE-2024-49973)In the Linux kernel, the following vulnerability has been resolved:  uprobes: fix kernel info leak via &#34;[uprobes]&#34; vma  xol_add_vma() maps the uninitialized page allocated by __create_xol_area() into userspace. On some architectures (x86) this memory is readable even without VM_READ, VM_EXEC results in the same pgprot_t as VM_EXEC|VM_READ, although this doesn&#39;t really matter, debugger can read this memory anyway.(CVE-2024-49975)In the Linux kernel, the following vulnerability has been resolved:  gso: fix udp gso fraglist segmentation after pull from frag_list  Detect gso fraglist skbs with corrupted geometry (see below) and pass these to skb_segment instead of skb_segment_list, as the first can segment them correctly.  Valid SKB_GSO_FRAGLIST skbs - consist of two or more segments - the head_skb holds the protocol headers plus first gso_size - one or more frag_list skbs hold exactly one segment - all but the last must be gso_size  Optional datapath hooks such as NAT and BPF (bpf_skb_pull_data) can modify these skbs, breaking these invariants.  In extreme cases they pull all data into skb linear. For UDP, this causes a NULL ptr deref in __udpv4_gso_segment_list_csum at udp_hdr(seg-&gt;next)-&gt;dest.  Detect invalid geometry due to pull, by checking head_skb size. Don&#39;t just drop, as this may blackhole a destination. Convert to be able to pass to regular skb_segment.(CVE-2024-49978)In the Linux kernel, the following vulnerability has been resolved:  media: venus: fix use after free bug in venus_remove due to race condition  in venus_probe, core-&gt;work is bound with venus_sys_error_handler, which is used to handle error. The code use core-&gt;sys_err_done to make sync work. The core-&gt;work is started in venus_event_notify.  If we call venus_remove, there might be an unfished work. The possible sequence is as follows:  CPU0                  CPU1                       |venus_sys_error_handler venus_remove         | hfi_destroy     | venus_hfi_destroy  | kfree(hdev);      |                      |hfi_reinit       |venus_hfi_queues_reinit                      |//use hdev  Fix it by canceling the work in venus_remove.(CVE-2024-49981)In the Linux kernel, the following vulnerability has been resolved:  drm/stm: Avoid use-after-free issues with crtc and plane  ltdc_load() calls functions drm_crtc_init_with_planes(), drm_universal_plane_init() and drm_encoder_init(). These functions should not be called with parameters allocated with devm_kzalloc() to avoid use-after-free issues [1].  Use allocations managed by the DRM framework.  Found by Linux Verification Center (linuxtesting.org).  [1] https://lore.kernel.org/lkml/u366i76e3qhh3ra5oxrtngjtm2u5lterkekcz6y2jkndhuxzli@diujon4h7qwb/(CVE-2024-49992)In the Linux kernel, the following vulnerability has been resolved:  tipc: guard against string buffer overrun  Smatch reports that copying media_name and if_name to name_parts may overwrite the destination.   .../bearer.c:166 bearer_name_validate() error: strcpy() &#39;media_name&#39; too large for &#39;name_parts-&gt;media_name&#39; (32 vs 16)  .../bearer.c:167 bearer_name_validate() error: strcpy() &#39;if_name&#39; too large for &#39;name_parts-&gt;if_name&#39; (1010102 vs 16)  This does seem to be the case so guard against this possibility by using strscpy() and failing if truncation occurs.  Introduced by commit b97bf3fd8f6a (&#34;[TIPC] Initial merge&#34;)  Compile tested only.(CVE-2024-49995)In the Linux kernel, the following vulnerability has been resolved:  cifs: Fix buffer overflow when parsing NFS reparse points  ReparseDataLength is sum of the InodeType size and DataBuffer size. So to get DataBuffer size it is needed to subtract InodeType&#39;s size from ReparseDataLength.  Function cifs_strndup_from_utf16() is currentlly accessing buf-&gt;DataBuffer at position after the end of the buffer because it does not subtract InodeType size from the length. Fix this problem and correctly subtract variable len.  Member InodeType is present only when reparse buffer is large enough. Check for ReparseDataLength before accessing InodeType to prevent another invalid memory access.  Major and minor rdev values are present also only when reparse buffer is large enough. Check for reparse buffer size before calling reparse_mkdev().(CVE-2024-49996)In the Linux kernel, the following vulnerability has been resolved:  static_call: Handle module init failure correctly in static_call_del_module()  Module insertion invokes static_call_add_module() to initialize the static calls in a module. static_call_add_module() invokes __static_call_init(), which allocates a struct static_call_mod to either encapsulate the built-in static call sites of the associated key into it so further modules can be added or to append the module to the module chain.  If that allocation fails the function returns with an error code and the module core invokes static_call_del_module() to clean up eventually added static_call_mod entries.  This works correctly, when all keys used by the module were converted over to a module chain before the failure. If not then static_call_del_module() causes a #GP as it blindly assumes that key::mods points to a valid struct static_call_mod.  The problem is that key::mods is not a individual struct member of struct static_call_key, it&#39;s part of a union to save space:          union {                 /* bit 0: 0 = mods, 1 = sites */                 unsigned long type;                 struct static_call_mod *mods;                 struct static_call_site *sites;  };  key::sites is a pointer to the list of built-in usage sites of the static call. The type of the pointer is differentiated by bit 0. A mods pointer has the bit clear, the sites pointer has the bit set.  As static_call_del_module() blidly assumes that the pointer is a valid static_call_mod type, it fails to check for this failure case and dereferences the pointer to the list of built-in call sites, which is obviously bogus.  Cure it by checking whether the key has a sites or a mods pointer.  If it&#39;s a sites pointer then the key is not to be touched. As the sites are walked in the same order as in __static_call_init() the site walk can be terminated because all subsequent sites have not been touched by the init code due to the error exit.  If it was converted before the allocation fail, then the inner loop which searches for a module match will find nothing.  A fail in the second allocation in __static_call_init() is harmless and does not require special treatment. The first allocation succeeded and converted the key to a module chain. That first entry has mod::mod == NULL and mod::next == NULL, so the inner loop of static_call_del_module() will neither find a module match nor a module chain. The next site in the walk was either already converted, but can&#39;t match the module, or it will exit the outer loop because it has a static_call_site pointer and not a static_call_mod pointer.(CVE-2024-50002)In the Linux kernel, the following vulnerability has been resolved:  ALSA: asihpi: Fix potential OOB array access  ASIHPI driver stores some values in the static array upon a response from the driver, and its index depends on the firmware.  We shouldn&#39;t trust it blindly.  This patch adds a sanity check of the array index to fit in the array size.(CVE-2024-50007)In the Linux kernel, the following vulnerability has been resolved:  wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_cmd_802_11_scan_ext()  Replace one-element array with a flexible-array member in `struct host_cmd_ds_802_11_scan_ext`.  With this, fix the following warning:  elo 16 17:51:58 surfacebook kernel: ------------[ cut here ]------------ elo 16 17:51:58 surfacebook kernel: memcpy: detected field-spanning write (size 243) of single field &#34;ext_scan-&gt;tlv_buffer&#34; at drivers/net/wireless/marvell/mwifiex/scan.c:2239 (size 1) elo 16 17:51:58 surfacebook kernel: WARNING: CPU: 0 PID: 498 at drivers/net/wireless/marvell/mwifiex/scan.c:2239 mwifiex_cmd_802_11_scan_ext+0x83/0x90 [mwifiex](CVE-2024-50008)In the Linux kernel, the following vulnerability has been resolved:  ext4: dax: fix overflowing extents beyond inode size when partially writing  The dax_iomap_rw() does two things in each iteration: map written blocks and copy user data to blocks. If the process is killed by user(See signal handling in dax_iomap_iter()), the copied data will be returned and added on inode size, which means that the length of written extents may exceed the inode size, then fsck will fail. An example is given as:  dd if=/dev/urandom of=file bs=4M count=1  dax_iomap_rw   iomap_iter // round 1    ext4_iomap_begin     ext4_iomap_alloc // allocate 0~2M extents(written flag)   dax_iomap_iter // copy 2M data   iomap_iter // round 2    iomap_iter_advance     iter-&gt;pos += iter-&gt;processed // iter-&gt;pos = 2M    ext4_iomap_begin     ext4_iomap_alloc // allocate 2~4M extents(written flag)   dax_iomap_iter    fatal_signal_pending   done = iter-&gt;pos - iocb-&gt;ki_pos // done = 2M  ext4_handle_inode_extension   ext4_update_inode_size // inode size = 2M  fsck reports: Inode 13, i_size is 2097152, should be 4194304.  Fix?  Fix the problem by truncating extents if the written length is smaller than expected.(CVE-2024-50015)In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Avoid overflow assignment in link_dp_cts  sampling_rate is an uint8_t but is assigned an unsigned int, and thus it can overflow. As a result, sampling_rate is changed to uint32_t.  Similarly, LINK_QUAL_PATTERN_SET has a size of 2 bits, and it should only be assigned to a value less or equal than 4.  This fixes 2 INTEGER_OVERFLOW issues reported by Coverity.(CVE-2024-50016)In the Linux kernel, the following vulnerability has been resolved:  thermal: core: Reference count the zone in thermal_zone_get_by_id()  There are places in the thermal netlink code where nothing prevents the thermal zone object from going away while being accessed after it has been returned by thermal_zone_get_by_id().  To address this, make thermal_zone_get_by_id() get a reference on the thermal zone device object to be returned with the help of get_device(), under thermal_list_lock, and adjust all of its callers to this change with the help of the cleanup.h infrastructure.(CVE-2024-50028)In the Linux kernel, the following vulnerability has been resolved:  slip: make slhc_remember() more robust against malicious packets  syzbot found that slhc_remember() was missing checks against malicious packets [1].  slhc_remember() only checked the size of the packet was at least 20, which is not good enough.  We need to make sure the packet includes the IPv4 and TCP header that are supposed to be carried.  Add iph and th pointers to make the code more readable.  [1]  BUG: KMSAN: uninit-value in slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666   slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666   ppp_receive_nonmp_frame+0xe45/0x35e0 drivers/net/ppp/ppp_generic.c:2455   ppp_receive_frame drivers/net/ppp/ppp_generic.c:2372 [inline]   ppp_do_recv+0x65f/0x40d0 drivers/net/ppp/ppp_generic.c:2212   ppp_input+0x7dc/0xe60 drivers/net/ppp/ppp_generic.c:2327   pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379   sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113   __release_sock+0x1da/0x330 net/core/sock.c:3072   release_sock+0x6b/0x250 net/core/sock.c:3626   pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903   sock_sendmsg_nosec net/socket.c:729 [inline]   __sock_sendmsg+0x30f/0x380 net/socket.c:744   ____sys_sendmsg+0x903/0xb60 net/socket.c:2602   ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656   __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742   __do_sys_sendmmsg net/socket.c:2771 [inline]   __se_sys_sendmmsg net/socket.c:2768 [inline]   __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768   x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308   do_syscall_x64 arch/x86/entry/common.c:52 [inline]   do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  Uninit was created at:   slab_post_alloc_hook mm/slub.c:4091 [inline]   slab_alloc_node mm/slub.c:4134 [inline]   kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186   kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587   __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678   alloc_skb include/linux/skbuff.h:1322 [inline]   sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732   pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867   sock_sendmsg_nosec net/socket.c:729 [inline]   __sock_sendmsg+0x30f/0x380 net/socket.c:744   ____sys_sendmsg+0x903/0xb60 net/socket.c:2602   ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656   __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742   __do_sys_sendmmsg net/socket.c:2771 [inline]   __se_sys_sendmmsg net/socket.c:2768 [inline]   __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768   x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308   do_syscall_x64 arch/x86/entry/common.c:52 [inline]   do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  CPU: 0 UID: 0 PID: 5460 Comm: syz.2.33 Not tainted 6.12.0-rc2-syzkaller-00006-g87d6aab2389e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024(CVE-2024-50033)In the Linux kernel, the following vulnerability has been resolved:  ppp: fix ppp_async_encode() illegal access  syzbot reported an issue in ppp_async_encode() [1]  In this case, pppoe_sendmsg() is called with a zero size. Then ppp_async_encode() is called with an empty skb.  BUG: KMSAN: uninit-value in ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline]  BUG: KMSAN: uninit-value in ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675   ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline]   ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675   ppp_async_send+0x130/0x1b0 drivers/net/ppp/ppp_async.c:634   ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2280 [inline]   ppp_input+0x1f1/0xe60 drivers/net/ppp/ppp_generic.c:2304   pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379   sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113   __release_sock+0x1da/0x330 net/core/sock.c:3072   release_sock+0x6b/0x250 net/core/sock.c:3626   pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903   sock_sendmsg_nosec net/socket.c:729 [inline]   __sock_sendmsg+0x30f/0x380 net/socket.c:744   ____sys_sendmsg+0x903/0xb60 net/socket.c:2602   ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656   __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742   __do_sys_sendmmsg net/socket.c:2771 [inline]   __se_sys_sendmmsg net/socket.c:2768 [inline]   __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768   x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308   do_syscall_x64 arch/x86/entry/common.c:52 [inline]   do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  Uninit was created at:   slab_post_alloc_hook mm/slub.c:4092 [inline]   slab_alloc_node mm/slub.c:4135 [inline]   kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4187   kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587   __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678   alloc_skb include/linux/skbuff.h:1322 [inline]   sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732   pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867   sock_sendmsg_nosec net/socket.c:729 [inline]   __sock_sendmsg+0x30f/0x380 net/socket.c:744   ____sys_sendmsg+0x903/0xb60 net/socket.c:2602   ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656   __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742   __do_sys_sendmmsg net/socket.c:2771 [inline]   __se_sys_sendmmsg net/socket.c:2768 [inline]   __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768   x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308   do_syscall_x64 arch/x86/entry/common.c:52 [inline]   do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  CPU: 1 UID: 0 PID: 5411 Comm: syz.1.14 Not tainted 6.12.0-rc1-syzkaller-00165-g360c1f1f24c6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024(CVE-2024-50035)In the Linux kernel, the following vulnerability has been resolved:  igb: Do not bring the device up after non-fatal error  Commit 004d25060c78 (&#34;igb: Fix igb_down hung on surprise removal&#34;) changed igb_io_error_detected() to ignore non-fatal pcie errors in order to avoid hung task that can happen when igb_down() is called multiple times. This caused an issue when processing transient non-fatal errors. igb_io_resume(), which is called after igb_io_error_detected(), assumes that device is brought down by igb_io_error_detected() if the interface is up. This resulted in panic with stacktrace below.  [ T3256] igb 0000:09:00.0 haeth0: igb: haeth0 NIC Link is Down [  T292] pcieport 0000:00:1c.5: AER: Uncorrected (Non-Fatal) error received: 0000:09:00.0 [  T292] igb 0000:09:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, (Requester ID) [  T292] igb 0000:09:00.0:   device [8086:1537] error status/mask=00004000/00000000 [  T292] igb 0000:09:00.0:    [14] CmpltTO [  200.105524,009][  T292] igb 0000:09:00.0: AER:   TLP Header: 00000000 00000000 00000000 00000000 [  T292] pcieport 0000:00:1c.5: AER: broadcast error_detected message [  T292] igb 0000:09:00.0: Non-correctable non-fatal error reported. [  T292] pcieport 0000:00:1c.5: AER: broadcast mmio_enabled message [  T292] pcieport 0000:00:1c.5: AER: broadcast resume message [  T292] ------------[ cut here ]------------ [  T292] kernel BUG at net/core/dev.c:6539! [  T292] invalid opcode: 0000 [#1] PREEMPT SMP [  T292] RIP: 0010:napi_enable+0x37/0x40 [  T292] Call Trace: [  T292]  &lt;TASK&gt; [  T292]  ? die+0x33/0x90 [  T292]  ? do_trap+0xdc/0x110 [  T292]  ? napi_enable+0x37/0x40 [  T292]  ? do_error_trap+0x70/0xb0 [  T292]  ? napi_enable+0x37/0x40 [  T292]  ? napi_enable+0x37/0x40 [  T292]  ? exc_invalid_op+0x4e/0x70 [  T292]  ? napi_enable+0x37/0x40 [  T292]  ? asm_exc_invalid_op+0x16/0x20 [  T292]  ? napi_enable+0x37/0x40 [  T292]  igb_up+0x41/0x150 [  T292]  igb_io_resume+0x25/0x70 [  T292]  report_resume+0x54/0x70 [  T292]  ? report_frozen_detected+0x20/0x20 [  T292]  pci_walk_bus+0x6c/0x90 [  T292]  ? aer_print_port_info+0xa0/0xa0 [  T292]  pcie_do_recovery+0x22f/0x380 [  T292]  aer_process_err_devices+0x110/0x160 [  T292]  aer_isr+0x1c1/0x1e0 [  T292]  ? disable_irq_nosync+0x10/0x10 [  T292]  irq_thread_fn+0x1a/0x60 [  T292]  irq_thread+0xe3/0x1a0 [  T292]  ? irq_set_affinity_notifier+0x120/0x120 [  T292]  ? irq_affinity_notify+0x100/0x100 [  T292]  kthread+0xe2/0x110 [  T292]  ? kthread_complete_and_exit+0x20/0x20 [  T292]  ret_from_fork+0x2d/0x50 [  T292]  ? kthread_complete_and_exit+0x20/0x20 [  T292]  ret_from_fork_asm+0x11/0x20 [  T292]  &lt;/TASK&gt;  To fix this issue igb_io_resume() checks if the interface is running and the device is not down this means igb_io_error_detected() did not bring the device down and there is no need to bring it up.(CVE-2024-50040)In the Linux kernel, the following vulnerability has been resolved:  smb: client: fix UAF in async decryption  Doing an async decryption (large read) crashes with a slab-use-after-free way down in the crypto API.  Reproducer:     # mount.cifs -o ...,seal,esize=1 //srv/share /mnt     # dd if=/mnt/largefile of=/dev/null     ...     [  194.196391] ==================================================================     [  194.196844] BUG: KASAN: slab-use-after-free in gf128mul_4k_lle+0xc1/0x110     [  194.197269] Read of size 8 at addr ffff888112bd0448 by task kworker/u77:2/899     [  194.197707]     [  194.197818] CPU: 12 UID: 0 PID: 899 Comm: kworker/u77:2 Not tainted 6.11.0-lku-00028-gfca3ca14a17a-dirty #43     [  194.198400] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014     [  194.199046] Workqueue: smb3decryptd smb2_decrypt_offload [cifs]     [  194.200032] Call Trace:     [  194.200191]  &lt;TASK&gt;     [  194.200327]  dump_stack_lvl+0x4e/0x70     [  194.200558]  ? gf128mul_4k_lle+0xc1/0x110     [  194.200809]  print_report+0x174/0x505     [  194.201040]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10     [  194.201352]  ? srso_return_thunk+0x5/0x5f     [  194.201604]  ? __virt_addr_valid+0xdf/0x1c0     [  194.201868]  ? gf128mul_4k_lle+0xc1/0x110     [  194.202128]  kasan_report+0xc8/0x150     [  194.202361]  ? gf128mul_4k_lle+0xc1/0x110     [  194.202616]  gf128mul_4k_lle+0xc1/0x110     [  194.202863]  ghash_update+0x184/0x210     [  194.203103]  shash_ahash_update+0x184/0x2a0     [  194.203377]  ? __pfx_shash_ahash_update+0x10/0x10     [  194.203651]  ? srso_return_thunk+0x5/0x5f     [  194.203877]  ? crypto_gcm_init_common+0x1ba/0x340     [  194.204142]  gcm_hash_assoc_remain_continue+0x10a/0x140     [  194.204434]  crypt_message+0xec1/0x10a0 [cifs]     [  194.206489]  ? __pfx_crypt_message+0x10/0x10 [cifs]     [  194.208507]  ? srso_return_thunk+0x5/0x5f     [  194.209205]  ? srso_return_thunk+0x5/0x5f     [  194.209925]  ? srso_return_thunk+0x5/0x5f     [  194.210443]  ? srso_return_thunk+0x5/0x5f     [  194.211037]  decrypt_raw_data+0x15f/0x250 [cifs]     [  194.212906]  ? __pfx_decrypt_raw_data+0x10/0x10 [cifs]     [  194.214670]  ? srso_return_thunk+0x5/0x5f     [  194.215193]  smb2_decrypt_offload+0x12a/0x6c0 [cifs]  This is because TFM is being used in parallel.  Fix this by allocating a new AEAD TFM for async decryption, but keep the existing one for synchronous READ cases (similar to what is done in smb3_calc_signature()).  Also remove the calls to aead_request_set_callback() and crypto_wait_req() since it&#39;s always going to be a synchronous operation.(CVE-2024-50047)In the Linux kernel, the following vulnerability has been resolved:  serial: protect uart_port_dtr_rts() in uart_shutdown() too  Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part 3) added few uport == NULL checks. It added one to uart_shutdown(), so the commit assumes, uport can be NULL in there. But right after that protection, there is an unprotected &#34;uart_port_dtr_rts(uport, false);&#34; call. That is invoked only if HUPCL is set, so I assume that is the reason why we do not see lots of these reports.  Or it cannot be NULL at this point at all for some reason :P.  Until the above is investigated, stay on the safe side and move this dereference to the if too.  I got this inconsistency from Coverity under CID 1585130. Thanks.(CVE-2024-50058)In the Linux kernel, the following vulnerability has been resolved:  ntb: ntb_hw_switchtec: Fix use after free vulnerability in switchtec_ntb_remove due to race condition  In the switchtec_ntb_add function, it can call switchtec_ntb_init_sndev function, then &amp;sndev-&gt;check_link_status_work is bound with check_link_status_work. switchtec_ntb_link_notification may be called to start the work.  If we remove the module which will call switchtec_ntb_remove to make cleanup, it will free sndev through kfree(sndev), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows:  CPU0                                 CPU1                          | check_link_status_work switchtec_ntb_remove    | kfree(sndev);           |                         | if (sndev-&gt;link_force_down)                         | // use sndev  Fix it by ensuring that the work is canceled before proceeding with the cleanup in switchtec_ntb_remove.(CVE-2024-50059)In the Linux kernel, the following vulnerability has been resolved:  io_uring: check if we need to reschedule during overflow flush  In terms of normal application usage, this list will always be empty. And if an application does overflow a bit, it&#39;ll have a few entries. However, nothing obviously prevents syzbot from running a test case that generates a ton of overflow entries, and then flushing them can take quite a while.  Check for needing to reschedule while flushing, and drop our locks and do so if necessary. There&#39;s no state to maintain here as overflows always prune from head-of-list, hence it&#39;s fine to drop and reacquire the locks at the end of the loop.(CVE-2024-50060)In the Linux kernel, the following vulnerability has been resolved:  bpf: Prevent tail call between progs attached to different hooks  bpf progs can be attached to kernel functions, and the attached functions can take different parameters or return different return values. If prog attached to one kernel function tail calls prog attached to another kernel function, the ctx access or return value verification could be bypassed.  For example, if prog1 is attached to func1 which takes only 1 parameter and prog2 is attached to func2 which takes two parameters. Since verifier assumes the bpf ctx passed to prog2 is constructed based on func2&#39;s prototype, verifier allows prog2 to access the second parameter from the bpf ctx passed to it. The problem is that verifier does not prevent prog1 from passing its bpf ctx to prog2 via tail call. In this case, the bpf ctx passed to prog2 is constructed from func1 instead of func2, that is, the assumption for ctx access verification is bypassed.  Another example, if BPF LSM prog1 is attached to hook file_alloc_security, and BPF LSM prog2 is attached to hook bpf_lsm_audit_rule_known. Verifier knows the return value rules for these two hooks, e.g. it is legal for bpf_lsm_audit_rule_known to return positive number 1, and it is illegal for file_alloc_security to return positive number. So verifier allows prog2 to return positive number 1, but does not allow prog1 to return positive number. The problem is that verifier does not prevent prog1 from calling prog2 via tail call. In this case, prog2&#39;s return value 1 will be used as the return value for prog1&#39;s hook file_alloc_security. That is, the return value rule is bypassed.  This patch adds restriction for tail call to prevent such bypasses.(CVE-2024-50063)In the Linux kernel, the following vulnerability has been resolved:  zram: free secondary algorithms names  We need to kfree() secondary algorithms names when reset zram device that had multi-streams, otherwise we leak memory.  [senozhatsky@chromium.org: kfree(NULL) is legal]   Link: https://lkml.kernel.org/r/20240917013021.868769-1-senozhatsky@chromium.org(CVE-2024-50064)In the Linux kernel, the following vulnerability has been resolved:  uprobe: avoid out-of-bounds memory access of fetching args  Uprobe needs to fetch args into a percpu buffer, and then copy to ring buffer to avoid non-atomic context problem.  Sometimes user-space strings, arrays can be very large, but the size of percpu buffer is only page size. And store_trace_args() won&#39;t check whether these data exceeds a single page or not, caused out-of-bounds memory access.  It could be reproduced by following steps: 1. build kernel with CONFIG_KASAN enabled 2. save follow program as test.c  ``` \#include &lt;stdio.h&gt; \#include &lt;stdlib.h&gt; \#include &lt;string.h&gt;  // If string length large than MAX_STRING_SIZE, the fetch_store_strlen() // will return 0, cause __get_data_size() return shorter size, and // store_trace_args() will not trigger out-of-bounds access. // So make string length less than 4096. \#define STRLEN 4093  void generate_string(char *str, int n) {     int i;     for (i = 0; i &lt; n; ++i)     {         char c = i % 26 + &#39;a&#39;;         str[i] = c;     }     str[n-1] = &#39;\0&#39;; }  void print_string(char *str) {     printf(&#34;%s\n&#34;, str); }  int main() {     char tmp[STRLEN];      generate_string(tmp, STRLEN);     print_string(tmp);      return 0; } ``` 3. compile program `gcc -o test test.c`  4. get the offset of `print_string()` ``` objdump -t test | grep -w print_string 0000000000401199 g     F .text  000000000000001b              print_string ```  5. configure uprobe with offset 0x1199 ``` off=0x1199  cd /sys/kernel/debug/tracing/ echo &#34;p /root/test:${off} arg1=+0(%di):ustring arg2=\$comm arg3=+0(%di):ustring&#34;  &gt; uprobe_events echo 1 &gt; events/uprobes/enable echo 1 &gt; tracing_on ```  6. run `test`, and kasan will report error. ================================================================== BUG: KASAN: use-after-free in strncpy_from_user+0x1d6/0x1f0 Write of size 8 at addr ffff88812311c004 by task test/499CPU: 0 UID: 0 PID: 499 Comm: test Not tainted 6.12.0-rc3+ #18 Hardware name: Red Hat KVM, BIOS 1.16.0-4.al8 04/01/2014 Call Trace:  &lt;TASK&gt;  dump_stack_lvl+0x55/0x70  print_address_description.constprop.0+0x27/0x310  kasan_report+0x10f/0x120  ? strncpy_from_user+0x1d6/0x1f0  strncpy_from_user+0x1d6/0x1f0  ? rmqueue.constprop.0+0x70d/0x2ad0  process_fetch_insn+0xb26/0x1470  ? __pfx_process_fetch_insn+0x10/0x10  ? _raw_spin_lock+0x85/0xe0  ? __pfx__raw_spin_lock+0x10/0x10  ? __pte_offset_map+0x1f/0x2d0  ? unwind_next_frame+0xc5f/0x1f80  ? arch_stack_walk+0x68/0xf0  ? is_bpf_text_address+0x23/0x30  ? kernel_text_address.part.0+0xbb/0xd0  ? __kernel_text_address+0x66/0xb0  ? unwind_get_return_address+0x5e/0xa0  ? __pfx_stack_trace_consume_entry+0x10/0x10  ? arch_stack_walk+0xa2/0xf0  ? _raw_spin_lock_irqsave+0x8b/0xf0  ? __pfx__raw_spin_lock_irqsave+0x10/0x10  ? depot_alloc_stack+0x4c/0x1f0  ? _raw_spin_unlock_irqrestore+0xe/0x30  ? stack_depot_save_flags+0x35d/0x4f0  ? kasan_save_stack+0x34/0x50  ? kasan_save_stack+0x24/0x50  ? mutex_lock+0x91/0xe0  ? __pfx_mutex_lock+0x10/0x10  prepare_uprobe_buffer.part.0+0x2cd/0x500  uprobe_dispatcher+0x2c3/0x6a0  ? __pfx_uprobe_dispatcher+0x10/0x10  ? __kasan_slab_alloc+0x4d/0x90  handler_chain+0xdd/0x3e0  handle_swbp+0x26e/0x3d0  ? __pfx_handle_swbp+0x10/0x10  ? uprobe_pre_sstep_notifier+0x151/0x1b0  irqentry_exit_to_user_mode+0xe2/0x1b0  asm_exc_int3+0x39/0x40 RIP: 0033:0x401199 Code: 01 c2 0f b6 45 fb 88 02 83 45 fc 01 8b 45 fc 3b 45 e4 7c b7 8b 45 e4 48 98 48 8d 50 ff 48 8b 45 e8 48 01 d0 ce RSP: 002b:00007ffdf00576a8 EFLAGS: 00000206 RAX: 00007ffdf00576b0 RBX: 0000000000000000 RCX: 0000000000000ff2 RDX: 0000000000000ffc RSI: 0000000000000ffd RDI: 00007ffdf00576b0 RBP: 00007ffdf00586b0 R08: 00007feb2f9c0d20 R09: 00007feb2f9c0d20 R10: 0000000000000001 R11: 0000000000000202 R12: 0000000000401040 R13: 00007ffdf0058780 R14: 0000000000000000 R15: 0000000000000000  &lt;/TASK&gt;  This commit enforces the buffer&#39;s maxlen less than a page-size to avoid store_trace_args() out-of-memory access.(CVE-2024-50067)In the Linux kernel, the following vulnerability has been resolved:  parport: Proper fix for array out-of-bounds access  The recent fix for array out-of-bounds accesses replaced sprintf() calls blindly with snprintf().  However, since snprintf() returns the would-be-printed size, not the actually output size, the length calculation can still go over the given limit.  Use scnprintf() instead of snprintf(), which returns the actually output letters, for addressing the potential out-of-bounds access properly.(CVE-2024-50074)In the Linux kernel, the following vulnerability has been resolved:  tcp: fix mptcp DSS corruption due to large pmtu xmit  Syzkaller was able to trigger a DSS corruption:    TCP: request_sock_subflow_v4: Possible SYN flooding on port [::]:20002. Sending cookies.   ------------[ cut here ]------------   WARNING: CPU: 0 PID: 5227 at net/mptcp/protocol.c:695 __mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695   Modules linked in:   CPU: 0 UID: 0 PID: 5227 Comm: syz-executor350 Not tainted 6.11.0-syzkaller-08829-gaf9c191ac2a0 #0   Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024   RIP: 0010:__mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695   Code: 0f b6 dc 31 ff 89 de e8 b5 dd ea f5 89 d8 48 81 c4 50 01 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 98 da ea f5 90 &lt;0f&gt; 0b 90 e9 47 ff ff ff e8 8a da ea f5 90 0f 0b 90 e9 99 e0 ff ff   RSP: 0018:ffffc90000006db8 EFLAGS: 00010246   RAX: ffffffff8ba9df18 RBX: 00000000000055f0 RCX: ffff888030023c00   RDX: 0000000000000100 RSI: 00000000000081e5 RDI: 00000000000055f0   RBP: 1ffff110062bf1ae R08: ffffffff8ba9cf12 R09: 1ffff110062bf1b8   R10: dffffc0000000000 R11: ffffed10062bf1b9 R12: 0000000000000000   R13: dffffc0000000000 R14: 00000000700cec61 R15: 00000000000081e5   FS:  000055556679c380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000   CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033   CR2: 0000000020287000 CR3: 0000000077892000 CR4: 00000000003506f0   DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000   DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400   Call Trace:    &lt;IRQ&gt;    move_skbs_to_msk net/mptcp/protocol.c:811 [inline]    mptcp_data_ready+0x29c/0xa90 net/mptcp/protocol.c:854    subflow_data_ready+0x34a/0x920 net/mptcp/subflow.c:1490    tcp_data_queue+0x20fd/0x76c0 net/ipv4/tcp_input.c:5283    tcp_rcv_established+0xfba/0x2020 net/ipv4/tcp_input.c:6237    tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915    tcp_v4_rcv+0x2dc0/0x37f0 net/ipv4/tcp_ipv4.c:2350    ip_protocol_deliver_rcu+0x22e/0x440 net/ipv4/ip_input.c:205    ip_local_deliver_finish+0x341/0x5f0 net/ipv4/ip_input.c:233    NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314    NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314    __netif_receive_skb_one_core net/core/dev.c:5662 [inline]    __netif_receive_skb+0x2bf/0x650 net/core/dev.c:5775    process_backlog+0x662/0x15b0 net/core/dev.c:6107    __napi_poll+0xcb/0x490 net/core/dev.c:6771    napi_poll net/core/dev.c:6840 [inline]    net_rx_action+0x89b/0x1240 net/core/dev.c:6962    handle_softirqs+0x2c5/0x980 kernel/softirq.c:554    do_softirq+0x11b/0x1e0 kernel/softirq.c:455    &lt;/IRQ&gt;    &lt;TASK&gt;    __local_bh_enable_ip+0x1bb/0x200 kernel/softirq.c:382    local_bh_enable include/linux/bottom_half.h:33 [inline]    rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline]    __dev_queue_xmit+0x1764/0x3e80 net/core/dev.c:4451    dev_queue_xmit include/linux/netdevice.h:3094 [inline]    neigh_hh_output include/net/neighbour.h:526 [inline]    neigh_output include/net/neighbour.h:540 [inline]    ip_finish_output2+0xd41/0x1390 net/ipv4/ip_output.c:236    ip_local_out net/ipv4/ip_output.c:130 [inline]    __ip_queue_xmit+0x118c/0x1b80 net/ipv4/ip_output.c:536    __tcp_transmit_skb+0x2544/0x3b30 net/ipv4/tcp_output.c:1466    tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline]    tcp_mtu_probe net/ipv4/tcp_output.c:2547 [inline]    tcp_write_xmit+0x641d/0x6bf0 net/ipv4/tcp_output.c:2752    __tcp_push_pending_frames+0x9b/0x360 net/ipv4/tcp_output.c:3015    tcp_push_pending_frames include/net/tcp.h:2107 [inline]    tcp_data_snd_check net/ipv4/tcp_input.c:5714 [inline]    tcp_rcv_established+0x1026/0x2020 net/ipv4/tcp_input.c:6239    tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915    sk_backlog_rcv include/net/sock.h:1113 [inline]    __release_sock+0x214/0x350 net/core/sock.c:3072    release_sock+0x61/0x1f0 net/core/sock.c:3626    mptcp_push_ ---truncated---(CVE-2024-50083)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="bpftool" release="235.0.0.134.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-235.0.0.134.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="235.0.0.134.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-235.0.0.134.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="235.0.0.134.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-235.0.0.134.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="235.0.0.134.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-235.0.0.134.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="235.0.0.134.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-235.0.0.134.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="235.0.0.134.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-235.0.0.134.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="235.0.0.134.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-235.0.0.134.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="235.0.0.134.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-235.0.0.134.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="235.0.0.134.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-235.0.0.134.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="235.0.0.134.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-235.0.0.134.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="235.0.0.134.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-235.0.0.134.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="235.0.0.134.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-235.0.0.134.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="235.0.0.134.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-235.0.0.134.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="235.0.0.134.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-235.0.0.134.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="235.0.0.134.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-235.0.0.134.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="235.0.0.134.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-235.0.0.134.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="235.0.0.134.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-235.0.0.134.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="235.0.0.134.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-235.0.0.134.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="235.0.0.134.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-235.0.0.134.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="235.0.0.134.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-235.0.0.134.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="235.0.0.134.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-235.0.0.134.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="235.0.0.134.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-235.0.0.134.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="235.0.0.134.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-235.0.0.134.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="235.0.0.134.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-235.0.0.134.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="235.0.0.134.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-235.0.0.134.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="235.0.0.134.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-235.0.0.134.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="235.0.0.134.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-235.0.0.134.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="235.0.0.134.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-235.0.0.134.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="235.0.0.134.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-235.0.0.134.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="235.0.0.134.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-235.0.0.134.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2374</id>
          <title>An update for python-waitress is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-11-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49769" id="CVE-2024-49769" title="CVE-2024-49769" type="cve"></reference>
          </references>
          <description>(CVE-2024-49769)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="python3-waitress" release="5.oe2203sp4" version="2.0.0">
                         <filename>python3-waitress-2.0.0-5.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2378</id>
          <title>An update for woodstox-core is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-11-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40152" id="CVE-2022-40152" title="CVE-2022-40152" type="cve"></reference>
          </references>
          <description>Those using Woodstox to parse XML data may be vulnerable to Denial of Service attacks (DOS) if DTD support is enabled. If the parser is running on user supplied input, an attacker may supply content that causes the parser to crash by stackoverflow. This effect may support a denial of service attack.(CVE-2022-40152)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="woodstox-core" release="2.oe2203sp4" version="5.0.3">
                         <filename>woodstox-core-5.0.3-2.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="woodstox-core-javadoc" release="2.oe2203sp4" version="5.0.3">
                         <filename>woodstox-core-javadoc-5.0.3-2.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2379</id>
          <title>An update for netty3 is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-11-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29025" id="CVE-2024-29025" title="CVE-2024-29025" type="cve"></reference>
          </references>
          <description>Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers &amp; clients. The `HttpPostRequestDecoder` can be tricked to accumulate data. While the decoder can store items on the disk if configured so, there are no limits to the number of fields the form can have, an attacher can send a chunked post consisting of many small fields that will be accumulated in the `bodyListHttpData` list. The decoder cumulates bytes in the `undecodedChunk` buffer until it can decode a field, this field can cumulate data without limits. This vulnerability is fixed in 4.1.108.Final.(CVE-2024-29025)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="netty3" release="9.oe2203sp4" version="3.10.6">
                         <filename>netty3-3.10.6-9.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2383</id>
          <title>An update for rubygem-actionmailer is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2024-11-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47889" id="CVE-2024-47889" title="CVE-2024-47889" type="cve"></reference>
          </references>
          <description>Action Mailer is a framework for designing email service layers. Starting in version 3.0.0 and prior to versions 6.1.7.9, 7.0.8.5, 7.1.4.1, and 7.2.1.1, there is a possible ReDoS vulnerability in the block_format helper in Action Mailer. Carefully crafted text can cause the block_format helper to take an unexpected amount of time, possibly resulting in a DoS vulnerability. All users running an affected release should either upgrade to versions 6.1.7.9, 7.0.8.5, 7.1.4.1, or 7.2.1.1 or apply the relevant patch immediately. As a workaround, users can avoid calling the `block_format` helper or upgrade to Ruby 3.2. Ruby 3.2 has mitigations for this problem, so Rails applications using Ruby 3.2 or newer are unaffected. Rails 8.0.0.beta1 requires Ruby 3.2 or greater so is unaffected.(CVE-2024-47889)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="noarch" name="rubygem-actionmailer" release="2.oe2203sp4" version="6.1.4.1">
                         <filename>rubygem-actionmailer-6.1.4.1-2.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="rubygem-actionmailer-doc" release="2.oe2203sp4" version="6.1.4.1">
                         <filename>rubygem-actionmailer-doc-6.1.4.1-2.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2387</id>
          <title>An update for openssl is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-11-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-9143" id="CVE-2024-9143" title="CVE-2024-9143" type="cve"></reference>
          </references>
          <description>Issue summary: Use of the low-level GF(2^m) elliptic curve APIs with untrustedexplicit values for the field polynomial can lead to out-of-bounds memory readsor writes.Impact summary: Out of bound memory writes can lead to an application crash oreven a possibility of a remote code execution, however, in all the protocolsinvolving Elliptic Curve Cryptography that we&#39;re aware of, either only &#34;namedcurves&#34; are supported, or, if explicit curve parameters are supported, theyspecify an X9.62 encoding of binary (GF(2^m)) curves that can&#39;t representproblematic input values. Thus the likelihood of existence of a vulnerableapplication is low.In particular, the X9.62 encoding is used for ECC keys in X.509 certificates,so problematic inputs cannot occur in the context of processing X.509certificates.  Any problematic use-cases would have to be using an &#34;exotic&#34;curve encoding.The affected APIs include: EC_GROUP_new_curve_GF2m(), EC_GROUP_new_from_params(),and various supporting BN_GF2m_*() functions.Applications working with &#34;exotic&#34; explicit binary (GF(2^m)) curve parameters,that make it possible to represent invalid field polynomials with a zeroconstant term, via the above or similar APIs, may terminate abruptly as aresult of reading or writing outside of array bounds.  Remote code executioncannot easily be ruled out.The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.(CVE-2024-9143)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="openssl" release="10.oe2203sp4" version="1.1.1wa">
                         <filename>openssl-1.1.1wa-10.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="openssl-debuginfo" release="10.oe2203sp4" version="1.1.1wa">
                         <filename>openssl-debuginfo-1.1.1wa-10.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="openssl-debugsource" release="10.oe2203sp4" version="1.1.1wa">
                         <filename>openssl-debugsource-1.1.1wa-10.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="openssl-devel" release="10.oe2203sp4" version="1.1.1wa">
                         <filename>openssl-devel-1.1.1wa-10.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="openssl-libs" release="10.oe2203sp4" version="1.1.1wa">
                         <filename>openssl-libs-1.1.1wa-10.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="openssl-perl" release="10.oe2203sp4" version="1.1.1wa">
                         <filename>openssl-perl-1.1.1wa-10.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="openssl-help" release="10.oe2203sp4" version="1.1.1wa">
                         <filename>openssl-help-1.1.1wa-10.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl" release="10.oe2203sp4" version="1.1.1wa">
                         <filename>openssl-1.1.1wa-10.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl-debuginfo" release="10.oe2203sp4" version="1.1.1wa">
                         <filename>openssl-debuginfo-1.1.1wa-10.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl-debugsource" release="10.oe2203sp4" version="1.1.1wa">
                         <filename>openssl-debugsource-1.1.1wa-10.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl-devel" release="10.oe2203sp4" version="1.1.1wa">
                         <filename>openssl-devel-1.1.1wa-10.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl-libs" release="10.oe2203sp4" version="1.1.1wa">
                         <filename>openssl-libs-1.1.1wa-10.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl-perl" release="10.oe2203sp4" version="1.1.1wa">
                         <filename>openssl-perl-1.1.1wa-10.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2390</id>
          <title>An update for dhcp is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-11-15"></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>
          </references>
          <description>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)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="12" arch="aarch64" name="dhcp" release="8.oe2203sp4" version="4.4.3">
                         <filename>dhcp-4.4.3-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="12" arch="aarch64" name="dhcp-debuginfo" release="8.oe2203sp4" version="4.4.3">
                         <filename>dhcp-debuginfo-4.4.3-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="12" arch="aarch64" name="dhcp-debugsource" release="8.oe2203sp4" version="4.4.3">
                         <filename>dhcp-debugsource-4.4.3-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="12" arch="aarch64" name="dhcp-devel" release="8.oe2203sp4" version="4.4.3">
                         <filename>dhcp-devel-4.4.3-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="12" arch="noarch" name="dhcp-help" release="8.oe2203sp4" version="4.4.3">
                         <filename>dhcp-help-4.4.3-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="12" arch="x86_64" name="dhcp" release="8.oe2203sp4" version="4.4.3">
                         <filename>dhcp-4.4.3-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="12" arch="x86_64" name="dhcp-debuginfo" release="8.oe2203sp4" version="4.4.3">
                         <filename>dhcp-debuginfo-4.4.3-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="12" arch="x86_64" name="dhcp-debugsource" release="8.oe2203sp4" version="4.4.3">
                         <filename>dhcp-debugsource-4.4.3-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="12" arch="x86_64" name="dhcp-devel" release="8.oe2203sp4" version="4.4.3">
                         <filename>dhcp-devel-4.4.3-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2391</id>
          <title>An update for openjdk-1.8.0 is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-11-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21208" id="CVE-2024-21208" title="CVE-2024-21208" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21210" id="CVE-2024-21210" title="CVE-2024-21210" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21211" id="CVE-2024-21211" title="CVE-2024-21211" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21217" id="CVE-2024-21217" title="CVE-2024-21217" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21235" id="CVE-2024-21235" title="CVE-2024-21235" type="cve"></reference>
          </references>
          <description>Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Networking).  Supported versions that are affected are Oracle Java SE: 8u421, 8u421-perf, 11.0.24, 17.0.12, 21.0.4, 23; Oracle GraalVM for JDK: 17.0.12, 21.0.4, 23; Oracle GraalVM Enterprise Edition: 20.3.15 and  21.3.11. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 3.7 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).(CVE-2024-21208)Vulnerability in Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u421, 8u421-perf, 11.0.24, 17.0.12, 21.0.4 and  23. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).(CVE-2024-21210)Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Compiler).  Supported versions that are affected are Oracle Java SE: 23; Oracle GraalVM for JDK: 17.0.12, 21.0.4, 23; Oracle GraalVM Enterprise Edition: 20.3.15 and  21.3.11. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).(CVE-2024-21211)Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Serialization).  Supported versions that are affected are Oracle Java SE: 8u421, 8u421-perf, 11.0.24, 17.0.12, 21.0.4, 23; Oracle GraalVM for JDK: 17.0.12, 21.0.4, 23; Oracle GraalVM Enterprise Edition: 20.3.15 and  21.3.11. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).(CVE-2024-21217)Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u421, 8u421-perf, 11.0.24, 17.0.12, 21.0.4, 23;   Oracle GraalVM for JDK: 17.0.12, 21.0.4, 23;   Oracle GraalVM Enterprise Edition: 20.3.15 and  21.3.11. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as  unauthorized read access to a subset of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 4.8 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N).(CVE-2024-21235)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk" release="0.oe2203sp4" version="1.8.0.432.b06">
                         <filename>java-1.8.0-openjdk-1.8.0.432.b06-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-accessibility" release="0.oe2203sp4" version="1.8.0.432.b06">
                         <filename>java-1.8.0-openjdk-accessibility-1.8.0.432.b06-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-accessibility-slowdebug" release="0.oe2203sp4" version="1.8.0.432.b06">
                         <filename>java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.432.b06-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-debuginfo" release="0.oe2203sp4" version="1.8.0.432.b06">
                         <filename>java-1.8.0-openjdk-debuginfo-1.8.0.432.b06-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-debugsource" release="0.oe2203sp4" version="1.8.0.432.b06">
                         <filename>java-1.8.0-openjdk-debugsource-1.8.0.432.b06-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-demo" release="0.oe2203sp4" version="1.8.0.432.b06">
                         <filename>java-1.8.0-openjdk-demo-1.8.0.432.b06-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-demo-slowdebug" release="0.oe2203sp4" version="1.8.0.432.b06">
                         <filename>java-1.8.0-openjdk-demo-slowdebug-1.8.0.432.b06-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-devel" release="0.oe2203sp4" version="1.8.0.432.b06">
                         <filename>java-1.8.0-openjdk-devel-1.8.0.432.b06-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-devel-slowdebug" release="0.oe2203sp4" version="1.8.0.432.b06">
                         <filename>java-1.8.0-openjdk-devel-slowdebug-1.8.0.432.b06-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-headless" release="0.oe2203sp4" version="1.8.0.432.b06">
                         <filename>java-1.8.0-openjdk-headless-1.8.0.432.b06-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-headless-slowdebug" release="0.oe2203sp4" version="1.8.0.432.b06">
                         <filename>java-1.8.0-openjdk-headless-slowdebug-1.8.0.432.b06-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-openjfx" release="0.oe2203sp4" version="1.8.0.432.b06">
                         <filename>java-1.8.0-openjdk-openjfx-1.8.0.432.b06-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-openjfx-devel" release="0.oe2203sp4" version="1.8.0.432.b06">
                         <filename>java-1.8.0-openjdk-openjfx-devel-1.8.0.432.b06-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-openjfx-devel-slowdebug" release="0.oe2203sp4" version="1.8.0.432.b06">
                         <filename>java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.432.b06-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-openjfx-slowdebug" release="0.oe2203sp4" version="1.8.0.432.b06">
                         <filename>java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.432.b06-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-slowdebug" release="0.oe2203sp4" version="1.8.0.432.b06">
                         <filename>java-1.8.0-openjdk-slowdebug-1.8.0.432.b06-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-src" release="0.oe2203sp4" version="1.8.0.432.b06">
                         <filename>java-1.8.0-openjdk-src-1.8.0.432.b06-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-src-slowdebug" release="0.oe2203sp4" version="1.8.0.432.b06">
                         <filename>java-1.8.0-openjdk-src-slowdebug-1.8.0.432.b06-0.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="java-1.8.0-openjdk-javadoc" release="0.oe2203sp4" version="1.8.0.432.b06">
                         <filename>java-1.8.0-openjdk-javadoc-1.8.0.432.b06-0.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="java-1.8.0-openjdk-javadoc-zip" release="0.oe2203sp4" version="1.8.0.432.b06">
                         <filename>java-1.8.0-openjdk-javadoc-zip-1.8.0.432.b06-0.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk" release="0.oe2203sp4" version="1.8.0.432.b06">
                         <filename>java-1.8.0-openjdk-1.8.0.432.b06-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-accessibility" release="0.oe2203sp4" version="1.8.0.432.b06">
                         <filename>java-1.8.0-openjdk-accessibility-1.8.0.432.b06-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-accessibility-slowdebug" release="0.oe2203sp4" version="1.8.0.432.b06">
                         <filename>java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.432.b06-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-debuginfo" release="0.oe2203sp4" version="1.8.0.432.b06">
                         <filename>java-1.8.0-openjdk-debuginfo-1.8.0.432.b06-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-debugsource" release="0.oe2203sp4" version="1.8.0.432.b06">
                         <filename>java-1.8.0-openjdk-debugsource-1.8.0.432.b06-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-demo" release="0.oe2203sp4" version="1.8.0.432.b06">
                         <filename>java-1.8.0-openjdk-demo-1.8.0.432.b06-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-demo-slowdebug" release="0.oe2203sp4" version="1.8.0.432.b06">
                         <filename>java-1.8.0-openjdk-demo-slowdebug-1.8.0.432.b06-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-devel" release="0.oe2203sp4" version="1.8.0.432.b06">
                         <filename>java-1.8.0-openjdk-devel-1.8.0.432.b06-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-devel-slowdebug" release="0.oe2203sp4" version="1.8.0.432.b06">
                         <filename>java-1.8.0-openjdk-devel-slowdebug-1.8.0.432.b06-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-headless" release="0.oe2203sp4" version="1.8.0.432.b06">
                         <filename>java-1.8.0-openjdk-headless-1.8.0.432.b06-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-headless-slowdebug" release="0.oe2203sp4" version="1.8.0.432.b06">
                         <filename>java-1.8.0-openjdk-headless-slowdebug-1.8.0.432.b06-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-openjfx" release="0.oe2203sp4" version="1.8.0.432.b06">
                         <filename>java-1.8.0-openjdk-openjfx-1.8.0.432.b06-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-openjfx-devel" release="0.oe2203sp4" version="1.8.0.432.b06">
                         <filename>java-1.8.0-openjdk-openjfx-devel-1.8.0.432.b06-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-openjfx-devel-slowdebug" release="0.oe2203sp4" version="1.8.0.432.b06">
                         <filename>java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.432.b06-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-openjfx-slowdebug" release="0.oe2203sp4" version="1.8.0.432.b06">
                         <filename>java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.432.b06-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-slowdebug" release="0.oe2203sp4" version="1.8.0.432.b06">
                         <filename>java-1.8.0-openjdk-slowdebug-1.8.0.432.b06-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-src" release="0.oe2203sp4" version="1.8.0.432.b06">
                         <filename>java-1.8.0-openjdk-src-1.8.0.432.b06-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-src-slowdebug" release="0.oe2203sp4" version="1.8.0.432.b06">
                         <filename>java-1.8.0-openjdk-src-slowdebug-1.8.0.432.b06-0.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2395</id>
          <title>An update for netty is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-11-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29025" id="CVE-2024-29025" title="CVE-2024-29025" type="cve"></reference>
          </references>
          <description>Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers &amp; clients. The `HttpPostRequestDecoder` can be tricked to accumulate data. While the decoder can store items on the disk if configured so, there are no limits to the number of fields the form can have, an attacher can send a chunked post consisting of many small fields that will be accumulated in the `bodyListHttpData` list. The decoder cumulates bytes in the `undecodedChunk` buffer until it can decode a field, this field can cumulate data without limits. This vulnerability is fixed in 4.1.108.Final.(CVE-2024-29025)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="netty" release="22.oe2203sp4" version="4.1.13">
                         <filename>netty-4.1.13-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="netty-help" release="22.oe2203sp4" version="4.1.13">
                         <filename>netty-help-4.1.13-22.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="netty" release="22.oe2203sp4" version="4.1.13">
                         <filename>netty-4.1.13-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2400</id>
          <title>An update for xstream is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-11-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47072" id="CVE-2024-47072" title="CVE-2024-47072" type="cve"></reference>
          </references>
          <description>XStream provides a BinaryStreamDriver with an own optimized serialization format. The format uses ids for string values as deduplication. The mapping for these ids are created on-the-fly at marshalling time. At unmarshalling time the reader_x27;s implementation simply used a simple one-time recursion after reading a mapping token to process the next normal token of the data stream. However, an endless recursion could be triggered with manipulated input data resulting in a stack overflow causing a denial of service.(CVE-2024-47072)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="xstream" release="2.oe2203sp4" version="1.4.20">
                         <filename>xstream-1.4.20-2.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="xstream-benchmark" release="2.oe2203sp4" version="1.4.20">
                         <filename>xstream-benchmark-1.4.20-2.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="xstream-hibernate" release="2.oe2203sp4" version="1.4.20">
                         <filename>xstream-hibernate-1.4.20-2.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="xstream-javadoc" release="2.oe2203sp4" version="1.4.20">
                         <filename>xstream-javadoc-1.4.20-2.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="xstream-parent" release="2.oe2203sp4" version="1.4.20">
                         <filename>xstream-parent-1.4.20-2.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2405</id>
          <title>An update for tomcat is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-11-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-43980" id="CVE-2021-43980" title="CVE-2021-43980" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-25762" id="CVE-2022-25762" title="CVE-2022-25762" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-44487" id="CVE-2023-44487" title="CVE-2023-44487" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46589" id="CVE-2023-46589" title="CVE-2023-46589" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-23672" id="CVE-2024-23672" title="CVE-2024-23672" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24549" id="CVE-2024-24549" title="CVE-2024-24549" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-34750" id="CVE-2024-34750" title="CVE-2024-34750" type="cve"></reference>
          </references>
          <description>The simplified implementation of blocking reads and writes introduced in Tomcat 10 and back-ported to Tomcat 9.0.47 onwards exposed a long standing (but extremely hard to trigger) concurrency bug in Apache Tomcat 10.1.0 to 10.1.0-M12, 10.0.0-M1 to 10.0.18, 9.0.0-M1 to 9.0.60 and 8.5.0 to 8.5.77 that could cause client connections to share an Http11Processor instance resulting in responses, or part responses, to be received by the wrong client.(CVE-2021-43980)If a web application sends a WebSocket message concurrently with the WebSocket connection closing when running on Apache Tomcat 8.5.0 to 8.5.75 or Apache Tomcat 9.0.0.M1 to 9.0.20, it is possible that the application will continue to use the socket after it has been closed. The error handling triggered in this case could cause the a pooled object to be placed in the pool twice. This could result in subsequent connections using the same object concurrently which could result in data being returned to the wrong use and/or other errors.(CVE-2022-25762)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)Improper Input Validation vulnerability in Apache Tomcat.Tomcat from 11.0.0-M1 through 11.0.0-M10, from 10.1.0-M1 through 10.1.15, from 9.0.0-M1 through 9.0.82 and from 8.5.0 through 8.5.95 did not correctly parse HTTP trailer headers. A trailer header that exceeded the header size limit could cause Tomcat to treat a single request as multiple requests leading to the possibility of request smuggling when behind a reverse proxy.Users are recommended to upgrade to version 11.0.0-M11 onwards, 10.1.16 onwards, 9.0.83 onwards or 8.5.96 onwards, which fix the issue.(CVE-2023-46589)Denial of Service via incomplete cleanup vulnerability in Apache Tomcat. It was possible for WebSocket clients to keep WebSocket connections open leading to increased resource consumption.This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.0-M16, from 10.1.0-M1 through 10.1.18, from 9.0.0-M1 through 9.0.85, from 8.5.0 through 8.5.98.Users are recommended to upgrade to version 11.0.0-M17, 10.1.19, 9.0.86 or 8.5.99 which fix the issue.(CVE-2024-23672)Denial of Service due to improper input validation vulnerability for HTTP/2 requests in Apache Tomcat. When processing an HTTP/2 request, if the request exceeded any of the configured limits for headers, the associated HTTP/2 stream was not reset until after all of the headers had been processed.This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.0-M16, from 10.1.0-M1 through 10.1.18, from 9.0.0-M1 through 9.0.85, from 8.5.0 through 8.5.98.Users are recommended to upgrade to version 11.0.0-M17, 10.1.19, 9.0.86 or 8.5.99 which fix the issue.(CVE-2024-24549)Improper Handling of Exceptional Conditions, Uncontrolled Resource Consumption vulnerability in Apache Tomcat. When processing an HTTP/2 stream, Tomcat did not handle some cases of excessive HTTP headers correctly. This led to a miscounting of active HTTP/2 streams which in turn led to the use of an incorrect infinite timeout which allowed connections to remain open which should have been closed.This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.0-M20, from 10.1.0-M1 through 10.1.24, from 9.0.0-M1 through 9.0.89.Users are recommended to upgrade to version 11.0.0-M21, 10.1.25 or 9.0.90, which fixes the issue.(CVE-2024-34750)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="noarch" name="tomcat" release="1.oe2203sp4" version="9.0.96">
                         <filename>tomcat-9.0.96-1.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="tomcat-help" release="1.oe2203sp4" version="9.0.96">
                         <filename>tomcat-help-9.0.96-1.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="tomcat-jsvc" release="1.oe2203sp4" version="9.0.96">
                         <filename>tomcat-jsvc-9.0.96-1.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2410</id>
          <title>An update for hdf5 is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-11-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29166" id="CVE-2024-29166" title="CVE-2024-29166" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32606" id="CVE-2024-32606" title="CVE-2024-32606" type="cve"></reference>
          </references>
          <description>HDF5 through 1.14.3 contains a buffer overflow in H5O__linfo_decode, resulting in the corruption of the instruction pointer and causing denial of service or potential code execution.(CVE-2024-29166)HDF5 Library through 1.14.3 may attempt to dereference uninitialized values in h5tools_str_sprint in tools/lib/h5tools_str.c (called from h5tools_dump_simple_data in tools/lib/h5tools_dump.c).(CVE-2024-32606)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="hdf5" release="1.oe2203sp4" version="1.14.5">
                         <filename>hdf5-1.14.5-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hdf5-debuginfo" release="1.oe2203sp4" version="1.14.5">
                         <filename>hdf5-debuginfo-1.14.5-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hdf5-debugsource" release="1.oe2203sp4" version="1.14.5">
                         <filename>hdf5-debugsource-1.14.5-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hdf5-devel" release="1.oe2203sp4" version="1.14.5">
                         <filename>hdf5-devel-1.14.5-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hdf5-mpich" release="1.oe2203sp4" version="1.14.5">
                         <filename>hdf5-mpich-1.14.5-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hdf5-mpich-devel" release="1.oe2203sp4" version="1.14.5">
                         <filename>hdf5-mpich-devel-1.14.5-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hdf5-mpich-static" release="1.oe2203sp4" version="1.14.5">
                         <filename>hdf5-mpich-static-1.14.5-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hdf5-openmpi" release="1.oe2203sp4" version="1.14.5">
                         <filename>hdf5-openmpi-1.14.5-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hdf5-openmpi-devel" release="1.oe2203sp4" version="1.14.5">
                         <filename>hdf5-openmpi-devel-1.14.5-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hdf5-openmpi-static" release="1.oe2203sp4" version="1.14.5">
                         <filename>hdf5-openmpi-static-1.14.5-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hdf5" release="1.oe2203sp4" version="1.14.5">
                         <filename>hdf5-1.14.5-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hdf5-debuginfo" release="1.oe2203sp4" version="1.14.5">
                         <filename>hdf5-debuginfo-1.14.5-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hdf5-debugsource" release="1.oe2203sp4" version="1.14.5">
                         <filename>hdf5-debugsource-1.14.5-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hdf5-devel" release="1.oe2203sp4" version="1.14.5">
                         <filename>hdf5-devel-1.14.5-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hdf5-mpich" release="1.oe2203sp4" version="1.14.5">
                         <filename>hdf5-mpich-1.14.5-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hdf5-mpich-devel" release="1.oe2203sp4" version="1.14.5">
                         <filename>hdf5-mpich-devel-1.14.5-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hdf5-mpich-static" release="1.oe2203sp4" version="1.14.5">
                         <filename>hdf5-mpich-static-1.14.5-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hdf5-openmpi" release="1.oe2203sp4" version="1.14.5">
                         <filename>hdf5-openmpi-1.14.5-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hdf5-openmpi-devel" release="1.oe2203sp4" version="1.14.5">
                         <filename>hdf5-openmpi-devel-1.14.5-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hdf5-openmpi-static" release="1.oe2203sp4" version="1.14.5">
                         <filename>hdf5-openmpi-static-1.14.5-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2411</id>
          <title>An update for rubygem-actionpack is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2024-11-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41128" id="CVE-2024-41128" title="CVE-2024-41128" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47887" id="CVE-2024-47887" title="CVE-2024-47887" type="cve"></reference>
          </references>
          <description>Action Pack is a framework for handling and responding to web requests. Starting in version 3.1.0 and prior to versions 6.1.7.9, 7.0.8.5, 7.1.4.1, and 7.2.1.1, there is a possible ReDoS vulnerability in the query parameter filtering routines of Action Dispatch. Carefully crafted query parameters can cause query parameter filtering to take an unexpected amount of time, possibly resulting in a DoS vulnerability. All users running an affected release should either upgrade to version 6.1.7.9, 7.0.8.5, 7.1.4.1, or 7.2.1.1 or apply the relevant patch immediately. One may use Ruby 3.2 as a workaround. Ruby 3.2 has mitigations for this problem, so Rails applications using Ruby 3.2 or newer are unaffected. Rails 8.0.0.beta1 depends on Ruby 3.2 or greater so is unaffected.(CVE-2024-41128)Action Pack is a framework for handling and responding to web requests. Starting in version 4.0.0 and prior to versions 6.1.7.9, 7.0.8.5, 7.1.4.1, and 7.2.1.1, there is a possible ReDoS vulnerability in Action Controller&#39;s HTTP Token authentication. For applications using HTTP Token authentication via `authenticate_or_request_with_http_token` or similar, a carefully crafted header may cause header parsing to take an unexpected amount of time, possibly resulting in a DoS vulnerability. All users running an affected release should either upgrade to versions 6.1.7.9, 7.0.8.5, 7.1.4.1, or 7.2.1.1 or apply the relevant patch immediately. One may choose to use Ruby 3.2 as a workaround.Ruby 3.2 has mitigations for this problem, so Rails applications using Ruby 3.2 or newer are unaffected. Rails 8.0.0.beta1 depends on Ruby 3.2 or greater so is unaffected.(CVE-2024-47887)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="noarch" name="rubygem-actionpack" release="7.oe2203sp4" version="6.1.4.1">
                         <filename>rubygem-actionpack-6.1.4.1-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="rubygem-actionpack-doc" release="7.oe2203sp4" version="6.1.4.1">
                         <filename>rubygem-actionpack-doc-6.1.4.1-7.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2418</id>
          <title>An update for mosquitto is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-11-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-8376" id="CVE-2024-8376" title="CVE-2024-8376" type="cve"></reference>
          </references>
          <description>In Eclipse Mosquitto up to version 2.0.18a, an attacker can achieve memory leaking, segmentation fault or heap-use-after-free by sending specific sequences of &#34;CONNECT&#34;, &#34;DISCONNECT&#34;, &#34;SUBSCRIBE&#34;, &#34;UNSUBSCRIBE&#34; and &#34;PUBLISH&#34; packets.(CVE-2024-8376)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="mosquitto" release="2.oe2203sp4" version="2.0.20">
                         <filename>mosquitto-2.0.20-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mosquitto-debuginfo" release="2.oe2203sp4" version="2.0.20">
                         <filename>mosquitto-debuginfo-2.0.20-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mosquitto-debugsource" release="2.oe2203sp4" version="2.0.20">
                         <filename>mosquitto-debugsource-2.0.20-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mosquitto-devel" release="2.oe2203sp4" version="2.0.20">
                         <filename>mosquitto-devel-2.0.20-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mosquitto" release="2.oe2203sp4" version="2.0.20">
                         <filename>mosquitto-2.0.20-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mosquitto-debuginfo" release="2.oe2203sp4" version="2.0.20">
                         <filename>mosquitto-debuginfo-2.0.20-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mosquitto-debugsource" release="2.oe2203sp4" version="2.0.20">
                         <filename>mosquitto-debugsource-2.0.20-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mosquitto-devel" release="2.oe2203sp4" version="2.0.20">
                         <filename>mosquitto-devel-2.0.20-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2419</id>
          <title>An update for undertow is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-11-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1973" id="CVE-2023-1973" title="CVE-2023-1973" type="cve"></reference>
          </references>
          <description>A flaw was found in Undertow package. Using the FormAuthenticationMechanism, a malicious user could trigger a Denial of Service by sending crafted requests, leading the server to an OutofMemory error, exhausting the server&#39;s memory.(CVE-2023-1973)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="noarch" name="undertow" release="7.oe2203sp4" version="1.4.0">
                         <filename>undertow-1.4.0-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="undertow-javadoc" release="7.oe2203sp4" version="1.4.0">
                         <filename>undertow-javadoc-1.4.0-7.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2422</id>
          <title>An update for sbt is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-11-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46122" id="CVE-2023-46122" title="CVE-2023-46122" type="cve"></reference>
          </references>
          <description>sbt is a build tool for Scala, Java, and others. Given a specially crafted zip or JAR file, `IO.unzip` allows writing of arbitrary file. This would have potential to overwrite `/root/.ssh/authorized_keys`. Within sbt&#39;s main code, `IO.unzip` is used in `pullRemoteCache` task and `Resolvers.remote`; however many projects use `IO.unzip(...)` directly to implement custom tasks. This vulnerability has been patched in version 1.9.7.(CVE-2023-46122)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="sbt" release="3.oe2203sp4" version="0.13.1">
                         <filename>sbt-0.13.1-3.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2424</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-11-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46685" id="CVE-2024-46685" title="CVE-2024-46685" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46702" id="CVE-2024-46702" title="CVE-2024-46702" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46815" id="CVE-2024-46815" title="CVE-2024-46815" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47679" id="CVE-2024-47679" title="CVE-2024-47679" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49878" id="CVE-2024-49878" title="CVE-2024-49878" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49948" id="CVE-2024-49948" title="CVE-2024-49948" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49949" id="CVE-2024-49949" title="CVE-2024-49949" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49960" id="CVE-2024-49960" title="CVE-2024-49960" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49967" id="CVE-2024-49967" title="CVE-2024-49967" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49983" id="CVE-2024-49983" title="CVE-2024-49983" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50006" id="CVE-2024-50006" title="CVE-2024-50006" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50013" id="CVE-2024-50013" title="CVE-2024-50013" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50014" id="CVE-2024-50014" title="CVE-2024-50014" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50073" id="CVE-2024-50073" title="CVE-2024-50073" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50082" id="CVE-2024-50082" title="CVE-2024-50082" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50095" id="CVE-2024-50095" title="CVE-2024-50095" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50099" id="CVE-2024-50099" title="CVE-2024-50099" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50131" id="CVE-2024-50131" title="CVE-2024-50131" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50133" id="CVE-2024-50133" title="CVE-2024-50133" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50142" id="CVE-2024-50142" title="CVE-2024-50142" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50154" id="CVE-2024-50154" title="CVE-2024-50154" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50184" id="CVE-2024-50184" title="CVE-2024-50184" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:pinctrl: single: fix potential NULL dereference in pcs_get_function()pinmux_generic_get_function() can return NULL and the pointer &#39;function&#39;was dereferenced without checking against NULL. Add checking of pointer&#39;function&#39; in pcs_get_function().Found by code review.(CVE-2024-46685)In the Linux kernel, the following vulnerability has been resolved:thunderbolt: Mark XDomain as unplugged when router is removedI noticed that when we do discrete host router NVM upgrade and it getshot-removed from the PCIe side as a result of NVM firmware authentication,if there is another host connected with enabled paths we hang in tearingthem down. This is due to fact that the Thunderbolt networking driveralso tries to cleanup the paths and ends up blocking intb_disconnect_xdomain_paths() waiting for the domain lock.However, at this point we already cleaned the paths in tb_stop() sothere is really no need for tb_disconnect_xdomain_paths() to do thatanymore. Furthermore it already checks if the XDomain is unplugged andbails out early so take advantage of that and mark the XDomain asunplugged when we remove the parent router.(CVE-2024-46702)In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check num_valid_sets before accessing reader_wm_sets[][WHY &amp; HOW]num_valid_sets needs to be checked to avoid a negative index whenaccessing reader_wm_sets[num_valid_sets - 1].This fixes an OVERRUN issue reported by Coverity.(CVE-2024-46815)In the Linux kernel, the following vulnerability has been resolved:  vfs: fix race between evice_inodes() and find_inode()&amp;iput()  Hi, all  Recently I noticed a bug[1] in btrfs, after digged it into and I believe it&#39;a race in vfs.  Let&#39;s assume there&#39;s a inode (ie ino 261) with i_count 1 is called by iput(), and there&#39;s a concurrent thread calling generic_shutdown_super().  cpu0:                              cpu1: iput() // i_count is 1   -&gt;spin_lock(inode)   -&gt;dec i_count to 0   -&gt;iput_final()                    generic_shutdown_super()     -&gt;__inode_add_lru()               -&gt;evict_inodes()       // cause some reason[2]           -&gt;if (atomic_read(inode-&gt;i_count)) continue;       // return before                  // inode 261 passed the above check       // list_lru_add_obj()             // and then schedule out    -&gt;spin_unlock() // note here: the inode 261 // was still at sb list and hash list, // and I_FREEING|I_WILL_FREE was not been set  btrfs_iget()   // after some function calls   -&gt;find_inode()     // found the above inode 261     -&gt;spin_lock(inode)    // check I_FREEING|I_WILL_FREE    // and passed       -&gt;__iget()     -&gt;spin_unlock(inode)                // schedule back                                         -&gt;spin_lock(inode)                                         // check (I_NEW|I_FREEING|I_WILL_FREE) flags,                                         // passed and set I_FREEING iput()                                  -&gt;spin_unlock(inode)   -&gt;spin_lock(inode)     -&gt;evict()   // dec i_count to 0   -&gt;iput_final()     -&gt;spin_unlock()     -&gt;evict()  Now, we have two threads simultaneously evicting the same inode, which may trigger the BUG(inode-&gt;i_state &amp; I_CLEAR) statement both within clear_inode() and iput().  To fix the bug, recheck the inode-&gt;i_count after holding i_lock. Because in the most scenarios, the first check is valid, and the overhead of spin_lock() can be reduced.  If there is any misunderstanding, please let me know, thanks.  [1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/ [2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable() return false when I reproduced the bug.(CVE-2024-47679)In the Linux kernel, the following vulnerability has been resolved:  resource: fix region_intersects() vs add_memory_driver_managed()  On a system with CXL memory, the resource tree (/proc/iomem) related to CXL memory may look like something as follows.  490000000-50fffffff : CXL Window 0   490000000-50fffffff : region0     490000000-50fffffff : dax0.0       490000000-50fffffff : System RAM (kmem)  Because drivers/dax/kmem.c calls add_memory_driver_managed() during onlining CXL memory, which makes &#34;System RAM (kmem)&#34; a descendant of &#34;CXL Window X&#34;.  This confuses region_intersects(), which expects all &#34;System RAM&#34; resources to be at the top level of iomem_resource.  This can lead to bugs.  For example, when the following command line is executed to write some memory in CXL memory range via /dev/mem,   $ dd if=data of=/dev/mem bs=$((1 &lt;&lt; 10)) seek=$((0x490000000 &gt;&gt; 10)) count=1  dd: error writing &#39;/dev/mem&#39;: Bad address  1+0 records in  0+0 records out  0 bytes copied, 0.0283507 s, 0.0 kB/s  the command fails as expected.  However, the error code is wrong.  It should be &#34;Operation not permitted&#34; instead of &#34;Bad address&#34;.  More seriously, the /dev/mem permission checking in devmem_is_allowed() passes incorrectly.  Although the accessing is prevented later because ioremap() isn&#39;t allowed to map system RAM, it is a potential security issue.  During command executing, the following warning is reported in the kernel log for calling ioremap() on system RAM.   ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff  WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d  Call Trace:   memremap+0xcb/0x184   xlate_dev_mem_ptr+0x25/0x2f   write_mem+0x94/0xfb   vfs_write+0x128/0x26d   ksys_write+0xac/0xfe   do_syscall_64+0x9a/0xfd   entry_SYSCALL_64_after_hwframe+0x4b/0x53  The details of command execution process are as follows.  In the above resource tree, &#34;System RAM&#34; is a descendant of &#34;CXL Window 0&#34; instead of a top level resource.  So, region_intersects() will report no System RAM resources in the CXL memory region incorrectly, because it only checks the top level resources.  Consequently, devmem_is_allowed() will return 1 (allow access via /dev/mem) for CXL memory region incorrectly.  Fortunately, ioremap() doesn&#39;t allow to map System RAM and reject the access.  So, region_intersects() needs to be fixed to work correctly with the resource tree with &#34;System RAM&#34; not at top level as above.  To fix it, if we found a unmatched resource in the top level, we will continue to search matched resources in its descendant resources.  So, we will not miss any matched resources in resource tree anymore.  In the new implementation, an example resource tree  |------------- &#34;CXL Window 0&#34; ------------| |-- &#34;System RAM&#34; --|  will behave similar as the following fake resource tree for region_intersects(, IORESOURCE_SYSTEM_RAM, ),  |-- &#34;System RAM&#34; --||-- &#34;CXL Window 0a&#34; --|  Where &#34;CXL Window 0a&#34; is part of the original &#34;CXL Window 0&#34; that isn&#39;t covered by &#34;System RAM&#34;.(CVE-2024-49878)In the Linux kernel, the following vulnerability has been resolved:  net: add more sanity checks to qdisc_pkt_len_init()  One path takes care of SKB_GSO_DODGY, assuming skb-&gt;len is bigger than hdr_len.  virtio_net_hdr_to_skb() does not fully dissect TCP headers, it only make sure it is at least 20 bytes.  It is possible for an user to provide a malicious &#39;GSO&#39; packet, total length of 80 bytes.  - 20 bytes of IPv4 header - 60 bytes TCP header - a small gso_size like 8  virtio_net_hdr_to_skb() would declare this packet as a normal GSO packet, because it would see 40 bytes of payload, bigger than gso_size.  We need to make detect this case to not underflow qdisc_skb_cb(skb)-&gt;pkt_len.(CVE-2024-49948)In the Linux kernel, the following vulnerability has been resolved:  net: avoid potential underflow in qdisc_pkt_len_init() with UFO  After commit 7c6d2ecbda83 (&#34;net: be more gentle about silly gso requests coming from user&#34;) virtio_net_hdr_to_skb() had sanity check to detect malicious attempts from user space to cook a bad GSO packet.  Then commit cf9acc90c80ec (&#34;net: virtio_net_hdr_to_skb: count transport header in UFO&#34;) while fixing one issue, allowed user space to cook a GSO packet with the following characteristic :  IPv4 SKB_GSO_UDP, gso_size=3, skb-&gt;len = 28.  When this packet arrives in qdisc_pkt_len_init(), we end up with hdr_len = 28 (IPv4 header + UDP header), matching skb-&gt;len  Then the following sets gso_segs to 0 :  gso_segs = DIV_ROUND_UP(skb-&gt;len - hdr_len,                         shinfo-&gt;gso_size);  Then later we set qdisc_skb_cb(skb)-&gt;pkt_len to back to zero :/  qdisc_skb_cb(skb)-&gt;pkt_len += (gso_segs - 1) * hdr_len;  This leads to the following crash in fq_codel [1]  qdisc_pkt_len_init() is best effort, we only want an estimation of the bytes sent on the wire, not crashing the kernel.  This patch is fixing this particular issue, a following one adds more sanity checks for another potential bug.  [1] [   70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000 [   70.724561] #PF: supervisor read access in kernel mode [   70.724561] #PF: error_code(0x0000) - not-present page [   70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0 [   70.724561] Oops: Oops: 0000 [#1] SMP NOPTI [   70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991 [   70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [   70.724561] RIP: 0010:fq_codel_enqueue (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel [ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 &lt;49&gt; 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49 All code ========    0: 24 08                 and    $0x8,%al    2: 49 c1 e1 06           shl    $0x6,%r9    6: 44 89 7c 24 18        mov    %r15d,0x18(%rsp)    b: 45 31 ed              xor    %r13d,%r13d    e: 45 31 c0              xor    %r8d,%r8d   11: 31 ff                 xor    %edi,%edi   13: 89 44 24 14           mov    %eax,0x14(%rsp)   17: 4c 03 8b 90 01 00 00  add    0x190(%rbx),%r9   1e: eb 04                 jmp    0x24   20: 39 ca                 cmp    %ecx,%edx   22: 73 37                 jae    0x5b   24: 4d 8b 39              mov    (%r9),%r15   27: 83 c7 01              add    $0x1,%edi   2a:* 49 8b 17              mov    (%r15),%rdx  &lt;-- trapping instruction   2d: 49 89 11              mov    %rdx,(%r9)   30: 41 8b 57 28           mov    0x28(%r15),%edx   34: 45 8b 5f 34           mov    0x34(%r15),%r11d   38: 49 c7 07 00 00 00 00  movq   $0x0,(%r15)   3f: 49                    rex.WB  Code starting with the faulting instruction ===========================================    0: 49 8b 17              mov    (%r15),%rdx    3: 49 89 11              mov    %rdx,(%r9)    6: 41 8b 57 28           mov    0x28(%r15),%edx    a: 45 8b 5f 34           mov    0x34(%r15),%r11d    e: 49 c7 07 00 00 00 00  movq   $0x0,(%r15)   15: 49                    rex.WB [   70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202 [   70.724561] RAX: 0000000002000000 RBX: ffff95ae841de000 RCX: 0000000000000000 [   70.724561] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001 [   70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09: ffff95b710a30000 [   70.724561] R10: 0000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58 [   70.724561] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000 [   70.724561] FS:  000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000 [   70.724561] CS:  0010 DS: 0000 ES: 0000 C ---truncated---(CVE-2024-49949)In the Linux kernel, the following vulnerability has been resolved:  ext4: fix timer use-after-free on failed mount  Syzbot has found an ODEBUG bug in ext4_fill_super  The del_timer_sync function cancels the s_err_report timer, which reminds about filesystem errors daily. We should guarantee the timer is no longer active before kfree(sbi).  When filesystem mounting fails, the flow goes to failed_mount3, where an error occurs when ext4_stop_mmpd is called, causing a read I/O failure. This triggers the ext4_handle_error function that ultimately re-arms the timer, leaving the s_err_report timer active before kfree(sbi) is called.  Fix the issue by canceling the s_err_report timer after calling ext4_stop_mmpd.(CVE-2024-49960)In the Linux kernel, the following vulnerability has been resolved:  ext4: no need to continue when the number of entries is 1(CVE-2024-49967)In the Linux kernel, the following vulnerability has been resolved:  ext4: drop ppath from ext4_ext_replay_update_ex() to avoid double-free  When calling ext4_force_split_extent_at() in ext4_ext_replay_update_ex(), the &#39;ppath&#39; is updated but it is the &#39;path&#39; that is freed, thus potentially triggering a double-free in the following process:  ext4_ext_replay_update_ex   ppath = path   ext4_force_split_extent_at(&amp;ppath)     ext4_split_extent_at       ext4_ext_insert_extent         ext4_ext_create_new_leaf           ext4_ext_grow_indepth             ext4_find_extent               if (depth &gt; path[0].p_maxdepth)                 kfree(path)                 ---&gt; path First freed                 *orig_path = path = NULL    ---&gt; null ppath   kfree(path)                               ---&gt; path double-free !!!  So drop the unnecessary ppath and use path directly to avoid this problem. And use ext4_find_extent() directly to update path, avoiding unnecessary memory allocation and freeing. Also, propagate the error returned by ext4_find_extent() instead of using strange error codes.(CVE-2024-49983)In the Linux kernel, the following vulnerability has been resolved:  ext4: fix i_data_sem unlock order in ext4_ind_migrate()  Fuzzing reports a possible deadlock in jbd2_log_wait_commit.  This issue is triggered when an EXT4_IOC_MIGRATE ioctl is set to require synchronous updates because the file descriptor is opened with O_SYNC. This can lead to the jbd2_journal_stop() function calling jbd2_might_wait_for_commit(), potentially causing a deadlock if the EXT4_IOC_MIGRATE call races with a write(2) system call.  This problem only arises when CONFIG_PROVE_LOCKING is enabled. In this case, the jbd2_might_wait_for_commit macro locks jbd2_handle in the jbd2_journal_stop function while i_data_sem is locked. This triggers lockdep because the jbd2_journal_start function might also lock the same jbd2_handle simultaneously.  Found by Linux Verification Center (linuxtesting.org) with syzkaller.  Rule: add(CVE-2024-50006)In the Linux kernel, the following vulnerability has been resolved:  exfat: fix memory leak in exfat_load_bitmap()  If the first directory entry in the root directory is not a bitmap directory entry, &#39;bh&#39; will not be released and reassigned, which will cause a memory leak.(CVE-2024-50013)In the Linux kernel, the following vulnerability has been resolved:  ext4: fix access to uninitialised lock in fc replay path  The following kernel trace can be triggered with fstest generic/629 when executed against a filesystem with fast-commit feature enabled:  INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn&#39;t initialize this object before use? turning off the locking correctness validator. CPU: 0 PID: 866 Comm: mount Not tainted 6.10.0+ #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014 Call Trace:  &lt;TASK&gt;  dump_stack_lvl+0x66/0x90  register_lock_class+0x759/0x7d0  __lock_acquire+0x85/0x2630  ? __find_get_block+0xb4/0x380  lock_acquire+0xd1/0x2d0  ? __ext4_journal_get_write_access+0xd5/0x160  _raw_spin_lock+0x33/0x40  ? __ext4_journal_get_write_access+0xd5/0x160  __ext4_journal_get_write_access+0xd5/0x160  ext4_reserve_inode_write+0x61/0xb0  __ext4_mark_inode_dirty+0x79/0x270  ? ext4_ext_replay_set_iblocks+0x2f8/0x450  ext4_ext_replay_set_iblocks+0x330/0x450  ext4_fc_replay+0x14c8/0x1540  ? jread+0x88/0x2e0  ? rcu_is_watching+0x11/0x40  do_one_pass+0x447/0xd00  jbd2_journal_recover+0x139/0x1b0  jbd2_journal_load+0x96/0x390  ext4_load_and_init_journal+0x253/0xd40  ext4_fill_super+0x2cc6/0x3180 ...  In the replay path there&#39;s an attempt to lock sbi-&gt;s_bdev_wb_lock in function ext4_check_bdev_write_error().  Unfortunately, at this point this spinlock has not been initialized yet.  Moving it&#39;s initialization to an earlier point in __ext4_fill_super() fixes this splat.(CVE-2024-50014)In the Linux kernel, the following vulnerability has been resolved:  tty: n_gsm: Fix use-after-free in gsm_cleanup_mux  BUG: KASAN: slab-use-after-free in gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] Read of size 8 at addr ffff88815fe99c00 by task poc/3379 CPU: 0 UID: 0 PID: 3379 Comm: poc Not tainted 6.11.0+ #56 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace:  &lt;TASK&gt;  gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm]  __pfx_gsm_cleanup_mux+0x10/0x10 drivers/tty/n_gsm.c:3124 [n_gsm]  __pfx_sched_clock_cpu+0x10/0x10 kernel/sched/clock.c:389  update_load_avg+0x1c1/0x27b0 kernel/sched/fair.c:4500  __pfx_min_vruntime_cb_rotate+0x10/0x10 kernel/sched/fair.c:846  __rb_insert_augmented+0x492/0xbf0 lib/rbtree.c:161  gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm]  _raw_spin_lock_irqsave+0x92/0xf0 arch/x86/include/asm/atomic.h:107  __pfx_gsmld_ioctl+0x10/0x10 drivers/tty/n_gsm.c:3822 [n_gsm]  ktime_get+0x5e/0x140 kernel/time/timekeeping.c:195  ldsem_down_read+0x94/0x4e0 arch/x86/include/asm/atomic64_64.h:79  __pfx_ldsem_down_read+0x10/0x10 drivers/tty/tty_ldsem.c:338  __pfx_do_vfs_ioctl+0x10/0x10 fs/ioctl.c:805  tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818  Allocated by task 65:  gsm_data_alloc.constprop.0+0x27/0x190 drivers/tty/n_gsm.c:926 [n_gsm]  gsm_send+0x2c/0x580 drivers/tty/n_gsm.c:819 [n_gsm]  gsm1_receive+0x547/0xad0 drivers/tty/n_gsm.c:3038 [n_gsm]  gsmld_receive_buf+0x176/0x280 drivers/tty/n_gsm.c:3609 [n_gsm]  tty_ldisc_receive_buf+0x101/0x1e0 drivers/tty/tty_buffer.c:391  tty_port_default_receive_buf+0x61/0xa0 drivers/tty/tty_port.c:39  flush_to_ldisc+0x1b0/0x750 drivers/tty/tty_buffer.c:445  process_scheduled_works+0x2b0/0x10d0 kernel/workqueue.c:3229  worker_thread+0x3dc/0x950 kernel/workqueue.c:3391  kthread+0x2a3/0x370 kernel/kthread.c:389  ret_from_fork+0x2d/0x70 arch/x86/kernel/process.c:147  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:257  Freed by task 3367:  kfree+0x126/0x420 mm/slub.c:4580  gsm_cleanup_mux+0x36c/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm]  gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm]  tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818  [Analysis] gsm_msg on the tx_ctrl_list or tx_data_list of gsm_mux can be freed by multi threads through ioctl,which leads to the occurrence of uaf. Protect it by gsm tx lock.(CVE-2024-50073)In the Linux kernel, the following vulnerability has been resolved:  blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race  We&#39;re seeing crashes from rq_qos_wake_function that look like this:    BUG: unable to handle page fault for address: ffffafe180a40084   #PF: supervisor write access in kernel mode   #PF: error_code(0x0002) - not-present page   PGD 100000067 P4D 100000067 PUD 10027c067 PMD 10115d067 PTE 0   Oops: Oops: 0002 [#1] PREEMPT SMP PTI   CPU: 17 UID: 0 PID: 0 Comm: swapper/17 Not tainted 6.12.0-rc3-00013-geca631b8fe80 #11   Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014   RIP: 0010:_raw_spin_lock_irqsave+0x1d/0x40   Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 9c 41 5c fa 65 ff 05 62 97 30 4c 31 c0 ba 01 00 00 00 &lt;f0&gt; 0f b1 17 75 0a 4c 89 e0 41 5c c3 cc cc cc cc 89 c6 e8 2c 0b 00   RSP: 0018:ffffafe180580ca0 EFLAGS: 00010046   RAX: 0000000000000000 RBX: ffffafe180a3f7a8 RCX: 0000000000000011   RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffffafe180a40084   RBP: 0000000000000000 R08: 00000000001e7240 R09: 0000000000000011   R10: 0000000000000028 R11: 0000000000000888 R12: 0000000000000002   R13: ffffafe180a40084 R14: 0000000000000000 R15: 0000000000000003   FS:  0000000000000000(0000) GS:ffff9aaf1f280000(0000) knlGS:0000000000000000   CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033   CR2: ffffafe180a40084 CR3: 000000010e428002 CR4: 0000000000770ef0   DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000   DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400   PKRU: 55555554   Call Trace:    &lt;IRQ&gt;    try_to_wake_up+0x5a/0x6a0    rq_qos_wake_function+0x71/0x80    __wake_up_common+0x75/0xa0    __wake_up+0x36/0x60    scale_up.part.0+0x50/0x110    wb_timer_fn+0x227/0x450    ...  So rq_qos_wake_function() calls wake_up_process(data-&gt;task), which calls try_to_wake_up(), which faults in raw_spin_lock_irqsave(&amp;p-&gt;pi_lock).  p comes from data-&gt;task, and data comes from the waitqueue entry, which is stored on the waiter&#39;s stack in rq_qos_wait(). Analyzing the core dump with drgn, I found that the waiter had already woken up and moved on to a completely unrelated code path, clobbering what was previously data-&gt;task. Meanwhile, the waker was passing the clobbered garbage in data-&gt;task to wake_up_process(), leading to the crash.  What&#39;s happening is that in between rq_qos_wake_function() deleting the waitqueue entry and calling wake_up_process(), rq_qos_wait() is finding that it already got a token and returning. The race looks like this:  rq_qos_wait()                           rq_qos_wake_function() ============================================================== prepare_to_wait_exclusive()                                         data-&gt;got_token = true;                                         list_del_init(&amp;curr-&gt;entry); if (data.got_token)         break; finish_wait(&amp;rqw-&gt;wait, &amp;data.wq);   ^- returns immediately because      list_empty_careful(&amp;wq_entry-&gt;entry)      is true ... return, go do something else ...                                         wake_up_process(data-&gt;task)                                           (NO LONGER VALID!)-^  Normally, finish_wait() is supposed to synchronize against the waker. But, as noted above, it is returning immediately because the waitqueue entry has already been removed from the waitqueue.  The bug is that rq_qos_wake_function() is accessing the waitqueue entry AFTER deleting it. Note that autoremove_wake_function() wakes the waiter and THEN deletes the waitqueue entry, which is the proper order.  Fix it by swapping the order. We also need to use list_del_init_careful() to match the list_empty_careful() in finish_wait().(CVE-2024-50082)In the Linux kernel, the following vulnerability has been resolved:  RDMA/mad: Improve handling of timed out WRs of mad agent  Current timeout handler of mad agent acquires/releases mad_agent_priv lock for every timed out WRs. This causes heavy locking contention when higher no. of WRs are to be handled inside timeout handler.  This leads to softlockup with below trace in some use cases where rdma-cm path is used to establish connection between peer nodes  Trace: -----  BUG: soft lockup - CPU#4 stuck for 26s! [kworker/u128:3:19767]  CPU: 4 PID: 19767 Comm: kworker/u128:3 Kdump: loaded Tainted: G OE      -------  ---  5.14.0-427.13.1.el9_4.x86_64 #1  Hardware name: Dell Inc. PowerEdge R740/01YM03, BIOS 2.4.8 11/26/2019  Workqueue: ib_mad1 timeout_sends [ib_core]  RIP: 0010:__do_softirq+0x78/0x2ac  RSP: 0018:ffffb253449e4f98 EFLAGS: 00000246  RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 000000000000001f  RDX: 000000000000001d RSI: 000000003d1879ab RDI: fff363b66fd3a86b  RBP: ffffb253604cbcd8 R08: 0000009065635f3b R09: 0000000000000000  R10: 0000000000000040 R11: ffffb253449e4ff8 R12: 0000000000000000  R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000040  FS:  0000000000000000(0000) GS:ffff8caa1fc80000(0000) knlGS:0000000000000000  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  CR2: 00007fd9ec9db900 CR3: 0000000891934006 CR4: 00000000007706e0  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400  PKRU: 55555554  Call Trace:   &lt;IRQ&gt;   ? show_trace_log_lvl+0x1c4/0x2df   ? show_trace_log_lvl+0x1c4/0x2df   ? __irq_exit_rcu+0xa1/0xc0   ? watchdog_timer_fn+0x1b2/0x210   ? __pfx_watchdog_timer_fn+0x10/0x10   ? __hrtimer_run_queues+0x127/0x2c0   ? hrtimer_interrupt+0xfc/0x210   ? __sysvec_apic_timer_interrupt+0x5c/0x110   ? sysvec_apic_timer_interrupt+0x37/0x90   ? asm_sysvec_apic_timer_interrupt+0x16/0x20   ? __do_softirq+0x78/0x2ac   ? __do_softirq+0x60/0x2ac   __irq_exit_rcu+0xa1/0xc0   sysvec_call_function_single+0x72/0x90   &lt;/IRQ&gt;   &lt;TASK&gt;   asm_sysvec_call_function_single+0x16/0x20  RIP: 0010:_raw_spin_unlock_irq+0x14/0x30  RSP: 0018:ffffb253604cbd88 EFLAGS: 00000247  RAX: 000000000001960d RBX: 0000000000000002 RCX: ffff8cad2a064800  RDX: 000000008020001b RSI: 0000000000000001 RDI: ffff8cad5d39f66c  RBP: ffff8cad5d39f600 R08: 0000000000000001 R09: 0000000000000000  R10: ffff8caa443e0c00 R11: ffffb253604cbcd8 R12: ffff8cacb8682538  R13: 0000000000000005 R14: ffffb253604cbd90 R15: ffff8cad5d39f66c   cm_process_send_error+0x122/0x1d0 [ib_cm]   timeout_sends+0x1dd/0x270 [ib_core]   process_one_work+0x1e2/0x3b0   ? __pfx_worker_thread+0x10/0x10   worker_thread+0x50/0x3a0   ? __pfx_worker_thread+0x10/0x10   kthread+0xdd/0x100   ? __pfx_kthread+0x10/0x10   ret_from_fork+0x29/0x50   &lt;/TASK&gt;  Simplified timeout handler by creating local list of timed out WRs and invoke send handler post creating the list. The new method acquires/ releases lock once to fetch the list and hence helps to reduce locking contetiong when processing higher no. of WRs(CVE-2024-50095)In the Linux kernel, the following vulnerability has been resolved:  arm64: probes: Remove broken LDR (literal) uprobe support  The simulate_ldr_literal() and simulate_ldrsw_literal() functions are unsafe to use for uprobes. Both functions were originally written for use with kprobes, and access memory with plain C accesses. When uprobes was added, these were reused unmodified even though they cannot safely access user memory.  There are three key problems:  1) The plain C accesses do not have corresponding extable entries, and    thus if they encounter a fault the kernel will treat these as    unintentional accesses to user memory, resulting in a BUG() which    will kill the kernel thread, and likely lead to further issues (e.g.    lockup or panic()).  2) The plain C accesses are subject to HW PAN and SW PAN, and so when    either is in use, any attempt to simulate an access to user memory    will fault. Thus neither simulate_ldr_literal() nor    simulate_ldrsw_literal() can do anything useful when simulating a    user instruction on any system with HW PAN or SW PAN.  3) The plain C accesses are privileged, as they run in kernel context,    and in practice can access a small range of kernel virtual addresses.    The instructions they simulate have a range of +/-1MiB, and since the    simulated instructions must itself be a user instructions in the    TTBR0 address range, these can address the final 1MiB of the TTBR1    acddress range by wrapping downwards from an address in the first    1MiB of the TTBR0 address range.     In contemporary kernels the last 8MiB of TTBR1 address range is    reserved, and accesses to this will always fault, meaning this is no    worse than (1).     Historically, it was theoretically possible for the linear map or    vmemmap to spill into the final 8MiB of the TTBR1 address range, but    in practice this is extremely unlikely to occur as this would    require either:     * Having enough physical memory to fill the entire linear map all the      way to the final 1MiB of the TTBR1 address range.     * Getting unlucky with KASLR randomization of the linear map such      that the populated region happens to overlap with the last 1MiB of      the TTBR address range.     ... and in either case if we were to spill into the final page there    would be larger problems as the final page would alias with error    pointers.  Practically speaking, (1) and (2) are the big issues. Given there have been no reports of problems since the broken code was introduced, it appears that no-one is relying on probing these instructions with uprobes.  Avoid these issues by not allowing uprobes on LDR (literal) and LDRSW (literal), limiting the use of simulate_ldr_literal() and simulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR (literal) and LDRSW (literal) will be rejected as arm_probe_decode_insn() will return INSN_REJECTED. In future we can consider introducing working uprobes support for these instructions, but this will require more significant work.(CVE-2024-50099)In the Linux kernel, the following vulnerability has been resolved:  tracing: Consider the NULL character when validating the event length  strlen() returns a string length excluding the null byte. If the string length equals to the maximum buffer length, the buffer will have no space for the NULL terminating character.  This commit checks this condition and returns failure for it.(CVE-2024-50131)In the Linux kernel, the following vulnerability has been resolved:  LoongArch: Don&#39;t crash in stack_top() for tasks without vDSO  Not all tasks have a vDSO mapped, for example kthreads never do. If such a task ever ends up calling stack_top(), it will derefence the NULL vdso pointer and crash.  This can for example happen when using kunit:   [&lt;9000000000203874&gt;] stack_top+0x58/0xa8  [&lt;90000000002956cc&gt;] arch_pick_mmap_layout+0x164/0x220  [&lt;90000000003c284c&gt;] kunit_vm_mmap_init+0x108/0x12c  [&lt;90000000003c1fbc&gt;] __kunit_add_resource+0x38/0x8c  [&lt;90000000003c2704&gt;] kunit_vm_mmap+0x88/0xc8  [&lt;9000000000410b14&gt;] usercopy_test_init+0xbc/0x25c  [&lt;90000000003c1db4&gt;] kunit_try_run_case+0x5c/0x184  [&lt;90000000003c3d54&gt;] kunit_generic_run_threadfn_adapter+0x24/0x48  [&lt;900000000022e4bc&gt;] kthread+0xc8/0xd4  [&lt;9000000000200ce8&gt;] ret_from_kernel_thread+0xc/0xa4(CVE-2024-50133)In the Linux kernel, the following vulnerability has been resolved:  xfrm: validate new SA&#39;s prefixlen using SA family when sel.family is unset  This expands the validation introduced in commit 07bf7908950a (&#34;xfrm: Validate address prefix lengths in the xfrm selector.&#34;)  syzbot created an SA with     usersa.sel.family = AF_UNSPEC     usersa.sel.prefixlen_s = 128     usersa.family = AF_INET  Because of the AF_UNSPEC selector, verify_newsa_info doesn&#39;t put limits on prefixlen_{s,d}. But then copy_from_user_state sets x-&gt;sel.family to usersa.family (AF_INET). Do the same conversion in verify_newsa_info before validating prefixlen_{s,d}, since that&#39;s how prefixlen is going to be used later on.(CVE-2024-50142)In the Linux kernel, the following vulnerability has been resolved:  tcp/dccp: Don&#39;t use timer_pending() in reqsk_queue_unlink().  Martin KaFai Lau reported use-after-free [0] in reqsk_timer_handler().    &#34;&#34;&#34;   We are seeing a use-after-free from a bpf prog attached to   trace_tcp_retransmit_synack. The program passes the req-&gt;sk to the   bpf_sk_storage_get_tracing kernel helper which does check for null   before using it.   &#34;&#34;&#34;  The commit 83fccfc3940c (&#34;inet: fix potential deadlock in reqsk_queue_unlink()&#34;) added timer_pending() in reqsk_queue_unlink() not to call del_timer_sync() from reqsk_timer_handler(), but it introduced a small race window.  Before the timer is called, expire_timers() calls detach_timer(timer, true) to clear timer-&gt;entry.pprev and marks it as not pending.  If reqsk_queue_unlink() checks timer_pending() just after expire_timers() calls detach_timer(), TCP will miss del_timer_sync(); the reqsk timer will continue running and send multiple SYN+ACKs until it expires.  The reported UAF could happen if req-&gt;sk is close()d earlier than the timer expiration, which is 63s by default.  The scenario would be    1. inet_csk_complete_hashdance() calls inet_csk_reqsk_queue_drop(),      but del_timer_sync() is missed    2. reqsk timer is executed and scheduled again    3. req-&gt;sk is accept()ed and reqsk_put() decrements rsk_refcnt, but      reqsk timer still has another one, and inet_csk_accept() does not      clear req-&gt;sk for non-TFO sockets    4. sk is close()d    5. reqsk timer is executed again, and BPF touches req-&gt;sk  Let&#39;s not use timer_pending() by passing the caller context to __inet_csk_reqsk_queue_drop().  Note that reqsk timer is pinned, so the issue does not happen in most use cases. [1]  [0] BUG: KFENCE: use-after-free read in bpf_sk_storage_get_tracing+0x2e/0x1b0  Use-after-free read at 0x00000000a891fb3a (in kfence-#1): bpf_sk_storage_get_tracing+0x2e/0x1b0 bpf_prog_5ea3e95db6da0438_tcp_retransmit_synack+0x1d20/0x1dda bpf_trace_run2+0x4c/0xc0 tcp_rtx_synack+0xf9/0x100 reqsk_timer_handler+0xda/0x3d0 run_timer_softirq+0x292/0x8a0 irq_exit_rcu+0xf5/0x320 sysvec_apic_timer_interrupt+0x6d/0x80 asm_sysvec_apic_timer_interrupt+0x16/0x20 intel_idle_irq+0x5a/0xa0 cpuidle_enter_state+0x94/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb  kfence-#1: 0x00000000a72cc7b6-0x00000000d97616d9, size=2376, cache=TCPv6  allocated by task 0 on cpu 9 at 260507.901592s: sk_prot_alloc+0x35/0x140 sk_clone_lock+0x1f/0x3f0 inet_csk_clone_lock+0x15/0x160 tcp_create_openreq_child+0x1f/0x410 tcp_v6_syn_recv_sock+0x1da/0x700 tcp_check_req+0x1fb/0x510 tcp_v6_rcv+0x98b/0x1420 ipv6_list_rcv+0x2258/0x26e0 napi_complete_done+0x5b1/0x2990 mlx5e_napi_poll+0x2ae/0x8d0 net_rx_action+0x13e/0x590 irq_exit_rcu+0xf5/0x320 common_interrupt+0x80/0x90 asm_common_interrupt+0x22/0x40 cpuidle_enter_state+0xfb/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb  freed by task 0 on cpu 9 at 260507.927527s: rcu_core_si+0x4ff/0xf10 irq_exit_rcu+0xf5/0x320 sysvec_apic_timer_interrupt+0x6d/0x80 asm_sysvec_apic_timer_interrupt+0x16/0x20 cpuidle_enter_state+0xfb/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb(CVE-2024-50154)In the Linux kernel, the following vulnerability has been resolved:  virtio_pmem: Check device status before requesting flush  If a pmem device is in a bad status, the driver side could wait for host ack forever in virtio_pmem_flush(), causing the system to hang.  So add a status check in the beginning of virtio_pmem_flush() to return early if the device is not activated.(CVE-2024-50184)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="bpftool" release="236.0.0.135.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-236.0.0.135.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="236.0.0.135.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-236.0.0.135.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="236.0.0.135.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-236.0.0.135.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="236.0.0.135.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-236.0.0.135.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="236.0.0.135.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-236.0.0.135.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="236.0.0.135.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-236.0.0.135.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="236.0.0.135.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-236.0.0.135.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="236.0.0.135.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-236.0.0.135.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="236.0.0.135.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-236.0.0.135.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="236.0.0.135.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-236.0.0.135.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="236.0.0.135.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-236.0.0.135.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="236.0.0.135.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-236.0.0.135.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="236.0.0.135.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-236.0.0.135.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="236.0.0.135.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-236.0.0.135.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="236.0.0.135.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-236.0.0.135.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="236.0.0.135.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-236.0.0.135.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="236.0.0.135.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-236.0.0.135.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="236.0.0.135.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-236.0.0.135.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="236.0.0.135.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-236.0.0.135.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="236.0.0.135.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-236.0.0.135.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="236.0.0.135.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-236.0.0.135.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="236.0.0.135.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-236.0.0.135.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="236.0.0.135.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-236.0.0.135.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="236.0.0.135.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-236.0.0.135.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="236.0.0.135.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-236.0.0.135.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="236.0.0.135.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-236.0.0.135.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="236.0.0.135.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-236.0.0.135.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="236.0.0.135.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-236.0.0.135.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="236.0.0.135.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-236.0.0.135.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="236.0.0.135.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-236.0.0.135.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2430</id>
          <title>An update for libpq is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-11-22"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0985" id="CVE-2024-0985" title="CVE-2024-0985" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-10976" id="CVE-2024-10976" title="CVE-2024-10976" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-10977" id="CVE-2024-10977" title="CVE-2024-10977" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-10978" id="CVE-2024-10978" title="CVE-2024-10978" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-10979" id="CVE-2024-10979" title="CVE-2024-10979" type="cve"></reference>
          </references>
          <description>Late privilege drop in REFRESH MATERIALIZED VIEW CONCURRENTLY in PostgreSQL allows an object creator to execute arbitrary SQL functions as the command issuer. The command intends to run SQL functions as the owner of the materialized view, enabling safe refresh of untrusted materialized views. The victim is a superuser or member of one of the attacker&#39;s roles. The attack requires luring the victim into running REFRESH MATERIALIZED VIEW CONCURRENTLY on the attacker&#39;s materialized view. Versions before PostgreSQL 16.2, 15.6, 14.11, 13.14, and 12.18 are affected.(CVE-2024-0985)Incomplete tracking in PostgreSQL of tables with row security allows a reused query to view or change different rows from those intended.  CVE-2023-2455 and CVE-2016-2193 fixed most interaction between row security and user ID changes.  They missed cases where a subquery, WITH query, security invoker view, or SQL-language function references a table with a row-level security policy.  This has the same consequences as the two earlier CVEs.  That is to say, it leads to potentially incorrect policies being applied in cases where role-specific policies are used and a given query is planned under one role and then executed under other roles.  This scenario can happen under security definer functions or when a common user and query is planned initially and then re-used across multiple SET ROLEs.  Applying an incorrect policy may permit a user to complete otherwise-forbidden reads and modifications.  This affects only databases that have used CREATE POLICY to define a row security policy.  An attacker must tailor an attack to a particular application&#39;s pattern of query plan reuse, user ID changes, and role-specific row security policies.  Versions before PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21 are affected.(CVE-2024-10976)Client use of server error message in PostgreSQL allows a server not trusted under current SSL or GSS settings to furnish arbitrary non-NUL bytes to the libpq application.  For example, a man-in-the-middle attacker could send a long error message that a human or screen-scraper user of psql mistakes for valid query results.  This is probably not a concern for clients where the user interface unambiguously indicates the boundary between one error message and other text.  Versions before PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21 are affected.(CVE-2024-10977)Incorrect privilege assignment in PostgreSQL allows a less-privileged application user to view or change different rows from those intended.  An attack requires the application to use SET ROLE, SET SESSION AUTHORIZATION, or an equivalent feature.  The problem arises when an application query uses parameters from the attacker or conveys query results to the attacker.  If that query reacts to current_setting(&#39;role&#39;) or the current user ID, it may modify or return data as though the session had not used SET ROLE or SET SESSION AUTHORIZATION.  The attacker does not control which incorrect user ID applies.  Query text from less-privileged sources is not a concern here, because SET ROLE and SET SESSION AUTHORIZATION are not sandboxes for unvetted queries.  Versions before PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21 are affected.(CVE-2024-10978)Incorrect control of environment variables in PostgreSQL PL/Perl allows an unprivileged database user to change sensitive process environment variables (e.g. PATH).  That often suffices to enable arbitrary code execution, even if the attacker lacks a database server operating system user.  Versions before PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21 are affected.(CVE-2024-10979)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libpq" release="1.oe2203sp4" version="13.17">
                         <filename>libpq-13.17-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libpq-debuginfo" release="1.oe2203sp4" version="13.17">
                         <filename>libpq-debuginfo-13.17-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libpq-debugsource" release="1.oe2203sp4" version="13.17">
                         <filename>libpq-debugsource-13.17-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libpq-devel" release="1.oe2203sp4" version="13.17">
                         <filename>libpq-devel-13.17-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libpq" release="1.oe2203sp4" version="13.17">
                         <filename>libpq-13.17-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libpq-debuginfo" release="1.oe2203sp4" version="13.17">
                         <filename>libpq-debuginfo-13.17-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libpq-debugsource" release="1.oe2203sp4" version="13.17">
                         <filename>libpq-debugsource-13.17-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libpq-devel" release="1.oe2203sp4" version="13.17">
                         <filename>libpq-devel-13.17-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2433</id>
          <title>An update for python-requests is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-11-22"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1682" id="CVE-2024-1682" title="CVE-2024-1682" type="cve"></reference>
          </references>
          <description>An unclaimed Amazon S3 bucket, &#39;codeconf&#39;, is referenced in an audio file link within the .rst documentation file. This bucket has been claimed by an external party. The use of this unclaimed S3 bucket could lead to data integrity issues, data leakage, availability problems, loss of trustworthiness, and potential further attacks if the bucket is used to host malicious content or as a pivot point for further attacks.(CVE-2024-1682)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="python-requests-help" release="9.oe2203sp4" version="2.26.0">
                         <filename>python-requests-help-2.26.0-9.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-requests" release="9.oe2203sp4" version="2.26.0">
                         <filename>python3-requests-2.26.0-9.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2435</id>
          <title>An update for glib2 is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2024-11-22"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-52533" id="CVE-2024-52533" title="CVE-2024-52533" type="cve"></reference>
          </references>
          <description>gio/gsocks4aproxy.c in GNOME GLib before 2.82.1 has an off-by-one error and resultant buffer overflow because SOCKS4_CONN_MSG_LEN is not sufficient for a trailing &#39;\0&#39; character.(CVE-2024-52533)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="glib2" release="19.oe2203sp4" version="2.72.2">
                         <filename>glib2-2.72.2-19.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glib2-debuginfo" release="19.oe2203sp4" version="2.72.2">
                         <filename>glib2-debuginfo-2.72.2-19.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glib2-debugsource" release="19.oe2203sp4" version="2.72.2">
                         <filename>glib2-debugsource-2.72.2-19.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glib2-devel" release="19.oe2203sp4" version="2.72.2">
                         <filename>glib2-devel-2.72.2-19.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glib2-static" release="19.oe2203sp4" version="2.72.2">
                         <filename>glib2-static-2.72.2-19.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glib2-tests" release="19.oe2203sp4" version="2.72.2">
                         <filename>glib2-tests-2.72.2-19.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="glib2-help" release="19.oe2203sp4" version="2.72.2">
                         <filename>glib2-help-2.72.2-19.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glib2" release="19.oe2203sp4" version="2.72.2">
                         <filename>glib2-2.72.2-19.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glib2-debuginfo" release="19.oe2203sp4" version="2.72.2">
                         <filename>glib2-debuginfo-2.72.2-19.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glib2-debugsource" release="19.oe2203sp4" version="2.72.2">
                         <filename>glib2-debugsource-2.72.2-19.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glib2-devel" release="19.oe2203sp4" version="2.72.2">
                         <filename>glib2-devel-2.72.2-19.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glib2-static" release="19.oe2203sp4" version="2.72.2">
                         <filename>glib2-static-2.72.2-19.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glib2-tests" release="19.oe2203sp4" version="2.72.2">
                         <filename>glib2-tests-2.72.2-19.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2439</id>
          <title>An update for busybox is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-11-22"></issued>
          <references>
               <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 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" release="23.oe2203sp4" version="1.34.1">
                         <filename>busybox-1.34.1-23.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="busybox-debuginfo" release="23.oe2203sp4" version="1.34.1">
                         <filename>busybox-debuginfo-1.34.1-23.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="busybox-debugsource" release="23.oe2203sp4" version="1.34.1">
                         <filename>busybox-debugsource-1.34.1-23.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="busybox-help" release="23.oe2203sp4" version="1.34.1">
                         <filename>busybox-help-1.34.1-23.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="busybox-petitboot" release="23.oe2203sp4" version="1.34.1">
                         <filename>busybox-petitboot-1.34.1-23.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="busybox" release="23.oe2203sp4" version="1.34.1">
                         <filename>busybox-1.34.1-23.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="busybox-debuginfo" release="23.oe2203sp4" version="1.34.1">
                         <filename>busybox-debuginfo-1.34.1-23.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="busybox-debugsource" release="23.oe2203sp4" version="1.34.1">
                         <filename>busybox-debugsource-1.34.1-23.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="busybox-help" release="23.oe2203sp4" version="1.34.1">
                         <filename>busybox-help-1.34.1-23.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="busybox-petitboot" release="23.oe2203sp4" version="1.34.1">
                         <filename>busybox-petitboot-1.34.1-23.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2442</id>
          <title>An update for openjdk-17 is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-11-22"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21208" id="CVE-2024-21208" title="CVE-2024-21208" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21210" id="CVE-2024-21210" title="CVE-2024-21210" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21217" id="CVE-2024-21217" title="CVE-2024-21217" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21235" id="CVE-2024-21235" title="CVE-2024-21235" type="cve"></reference>
          </references>
          <description>Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Networking).  Supported versions that are affected are Oracle Java SE: 8u421, 8u421-perf, 11.0.24, 17.0.12, 21.0.4, 23; Oracle GraalVM for JDK: 17.0.12, 21.0.4, 23; Oracle GraalVM Enterprise Edition: 20.3.15 and  21.3.11. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 3.7 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).(CVE-2024-21208)Vulnerability in Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u421, 8u421-perf, 11.0.24, 17.0.12, 21.0.4 and  23. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).(CVE-2024-21210)Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Serialization).  Supported versions that are affected are Oracle Java SE: 8u421, 8u421-perf, 11.0.24, 17.0.12, 21.0.4, 23; Oracle GraalVM for JDK: 17.0.12, 21.0.4, 23; Oracle GraalVM Enterprise Edition: 20.3.15 and  21.3.11. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).(CVE-2024-21217)Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u421, 8u421-perf, 11.0.24, 17.0.12, 21.0.4, 23;   Oracle GraalVM for JDK: 17.0.12, 21.0.4, 23;   Oracle GraalVM Enterprise Edition: 20.3.15 and  21.3.11. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as  unauthorized read access to a subset of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 4.8 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N).(CVE-2024-21235)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="java-17-openjdk" release="2.oe2203sp4" version="17.0.13.11">
                         <filename>java-17-openjdk-17.0.13.11-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-17-openjdk-debuginfo" release="2.oe2203sp4" version="17.0.13.11">
                         <filename>java-17-openjdk-debuginfo-17.0.13.11-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-17-openjdk-debugsource" release="2.oe2203sp4" version="17.0.13.11">
                         <filename>java-17-openjdk-debugsource-17.0.13.11-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-17-openjdk-demo" release="2.oe2203sp4" version="17.0.13.11">
                         <filename>java-17-openjdk-demo-17.0.13.11-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-17-openjdk-demo-slowdebug" release="2.oe2203sp4" version="17.0.13.11">
                         <filename>java-17-openjdk-demo-slowdebug-17.0.13.11-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-17-openjdk-devel" release="2.oe2203sp4" version="17.0.13.11">
                         <filename>java-17-openjdk-devel-17.0.13.11-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-17-openjdk-devel-slowdebug" release="2.oe2203sp4" version="17.0.13.11">
                         <filename>java-17-openjdk-devel-slowdebug-17.0.13.11-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-17-openjdk-headless" release="2.oe2203sp4" version="17.0.13.11">
                         <filename>java-17-openjdk-headless-17.0.13.11-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-17-openjdk-headless-slowdebug" release="2.oe2203sp4" version="17.0.13.11">
                         <filename>java-17-openjdk-headless-slowdebug-17.0.13.11-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-17-openjdk-javadoc" release="2.oe2203sp4" version="17.0.13.11">
                         <filename>java-17-openjdk-javadoc-17.0.13.11-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-17-openjdk-javadoc-zip" release="2.oe2203sp4" version="17.0.13.11">
                         <filename>java-17-openjdk-javadoc-zip-17.0.13.11-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-17-openjdk-jmods" release="2.oe2203sp4" version="17.0.13.11">
                         <filename>java-17-openjdk-jmods-17.0.13.11-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-17-openjdk-jmods-slowdebug" release="2.oe2203sp4" version="17.0.13.11">
                         <filename>java-17-openjdk-jmods-slowdebug-17.0.13.11-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-17-openjdk-slowdebug" release="2.oe2203sp4" version="17.0.13.11">
                         <filename>java-17-openjdk-slowdebug-17.0.13.11-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-17-openjdk-src" release="2.oe2203sp4" version="17.0.13.11">
                         <filename>java-17-openjdk-src-17.0.13.11-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-17-openjdk-src-slowdebug" release="2.oe2203sp4" version="17.0.13.11">
                         <filename>java-17-openjdk-src-slowdebug-17.0.13.11-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-17-openjdk" release="2.oe2203sp4" version="17.0.13.11">
                         <filename>java-17-openjdk-17.0.13.11-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-17-openjdk-debuginfo" release="2.oe2203sp4" version="17.0.13.11">
                         <filename>java-17-openjdk-debuginfo-17.0.13.11-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-17-openjdk-debugsource" release="2.oe2203sp4" version="17.0.13.11">
                         <filename>java-17-openjdk-debugsource-17.0.13.11-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-17-openjdk-demo" release="2.oe2203sp4" version="17.0.13.11">
                         <filename>java-17-openjdk-demo-17.0.13.11-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-17-openjdk-demo-slowdebug" release="2.oe2203sp4" version="17.0.13.11">
                         <filename>java-17-openjdk-demo-slowdebug-17.0.13.11-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-17-openjdk-devel" release="2.oe2203sp4" version="17.0.13.11">
                         <filename>java-17-openjdk-devel-17.0.13.11-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-17-openjdk-devel-slowdebug" release="2.oe2203sp4" version="17.0.13.11">
                         <filename>java-17-openjdk-devel-slowdebug-17.0.13.11-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-17-openjdk-headless" release="2.oe2203sp4" version="17.0.13.11">
                         <filename>java-17-openjdk-headless-17.0.13.11-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-17-openjdk-headless-slowdebug" release="2.oe2203sp4" version="17.0.13.11">
                         <filename>java-17-openjdk-headless-slowdebug-17.0.13.11-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-17-openjdk-javadoc" release="2.oe2203sp4" version="17.0.13.11">
                         <filename>java-17-openjdk-javadoc-17.0.13.11-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-17-openjdk-javadoc-zip" release="2.oe2203sp4" version="17.0.13.11">
                         <filename>java-17-openjdk-javadoc-zip-17.0.13.11-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-17-openjdk-jmods" release="2.oe2203sp4" version="17.0.13.11">
                         <filename>java-17-openjdk-jmods-17.0.13.11-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-17-openjdk-jmods-slowdebug" release="2.oe2203sp4" version="17.0.13.11">
                         <filename>java-17-openjdk-jmods-slowdebug-17.0.13.11-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-17-openjdk-slowdebug" release="2.oe2203sp4" version="17.0.13.11">
                         <filename>java-17-openjdk-slowdebug-17.0.13.11-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-17-openjdk-src" release="2.oe2203sp4" version="17.0.13.11">
                         <filename>java-17-openjdk-src-17.0.13.11-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-17-openjdk-src-slowdebug" release="2.oe2203sp4" version="17.0.13.11">
                         <filename>java-17-openjdk-src-slowdebug-17.0.13.11-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2447</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-11-22"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52920" id="CVE-2023-52920" title="CVE-2023-52920" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43911" id="CVE-2024-43911" title="CVE-2024-43911" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47663" id="CVE-2024-47663" title="CVE-2024-47663" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47666" id="CVE-2024-47666" title="CVE-2024-47666" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47728" id="CVE-2024-47728" title="CVE-2024-47728" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49914" id="CVE-2024-49914" title="CVE-2024-49914" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49945" id="CVE-2024-49945" title="CVE-2024-49945" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49963" id="CVE-2024-49963" title="CVE-2024-49963" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49982" id="CVE-2024-49982" title="CVE-2024-49982" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50115" id="CVE-2024-50115" title="CVE-2024-50115" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50138" id="CVE-2024-50138" title="CVE-2024-50138" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50151" id="CVE-2024-50151" title="CVE-2024-50151" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50153" id="CVE-2024-50153" title="CVE-2024-50153" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50198" id="CVE-2024-50198" title="CVE-2024-50198" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50203" id="CVE-2024-50203" title="CVE-2024-50203" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50237" id="CVE-2024-50237" title="CVE-2024-50237" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50242" id="CVE-2024-50242" title="CVE-2024-50242" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50244" id="CVE-2024-50244" title="CVE-2024-50244" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50245" id="CVE-2024-50245" title="CVE-2024-50245" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50246" id="CVE-2024-50246" title="CVE-2024-50246" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50247" id="CVE-2024-50247" title="CVE-2024-50247" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:  bpf: support non-r10 register spill/fill to/from stack in precision tracking  Use instruction (jump) history to record instructions that performed register spill/fill to/from stack, regardless if this was done through read-only r10 register, or any other register after copying r10 into it *and* potentially adjusting offset.  To make this work reliably, we push extra per-instruction flags into instruction history, encoding stack slot index (spi) and stack frame number in extra 10 bit flags we take away from prev_idx in instruction history. We don&#39;t touch idx field for maximum performance, as it&#39;s checked most frequently during backtracking.  This change removes basically the last remaining practical limitation of precision backtracking logic in BPF verifier. It fixes known deficiencies, but also opens up new opportunities to reduce number of verified states, explored in the subsequent patches.  There are only three differences in selftests&#39; BPF object files according to veristat, all in the positive direction (less states).  File                                    Program        Insns (A)  Insns (B)  Insns  (DIFF)  States (A)  States (B)  States (DIFF) --------------------------------------  -------------  ---------  ---------  -------------  ----------  ----------  ------------- test_cls_redirect_dynptr.bpf.linked3.o  cls_redirect        2987       2864  -123 (-4.12%)         240         231    -9 (-3.75%) xdp_synproxy_kern.bpf.linked3.o         syncookie_tc       82848      82661  -187 (-0.23%)        5107        5073   -34 (-0.67%) xdp_synproxy_kern.bpf.linked3.o         syncookie_xdp      85116      84964  -152 (-0.18%)        5162        5130   -32 (-0.62%)  Note, I avoided renaming jmp_history to more generic insn_hist to minimize number of lines changed and potential merge conflicts between bpf and bpf-next trees.  Notice also cur_hist_entry pointer reset to NULL at the beginning of instruction verification loop. This pointer avoids the problem of relying on last jump history entry&#39;s insn_idx to determine whether we already have entry for current instruction or not. It can happen that we added jump history entry because current instruction is_jmp_point(), but also we need to add instruction flags for stack access. In this case, we don&#39;t want to entries, so we need to reuse last added entry, if it is present.  Relying on insn_idx comparison has the same ambiguity problem as the one that was fixed recently in [0], so we avoid that.    [0] https://patchwork.kernel.org/project/netdevbpf/patch/20231110002638.4168352-3-andrii@kernel.org/(CVE-2023-52920)In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: fix NULL dereference at band check in starting tx ba sessionIn MLD connection, link_data/link_conf are dynamically allocated. Theydon&#39;t point to vif-&gt;bss_conf. So, there will be no chanreq assigned tovif-&gt;bss_conf and then the chan will be NULL. Tweak the code to checkht_supported/vht_supported/has_he/has_eht on sta deflink.Crash log (with rtw89 version under MLO development):[ 9890.526087] BUG: kernel NULL pointer dereference, address: 0000000000000000[ 9890.526102] #PF: supervisor read access in kernel mode[ 9890.526105] #PF: error_code(0x0000) - not-present page[ 9890.526109] PGD 0 P4D 0[ 9890.526114] Oops: 0000 [#1] PREEMPT SMP PTI[ 9890.526119] CPU: 2 PID: 6367 Comm: kworker/u16:2 Kdump: loaded Tainted: G           OE      6.9.0 #1[ 9890.526123] Hardware name: LENOVO 2356AD1/2356AD1, BIOS G7ETB3WW (2.73 ) 11/28/2018[ 9890.526126] Workqueue: phy2 rtw89_core_ba_work [rtw89_core][ 9890.526203] RIP: 0010:ieee80211_start_tx_ba_session (net/mac80211/agg-tx.c:618 (discriminator 1)) mac80211[ 9890.526279] Code: f7 e8 d5 93 3e ea 48 83 c4 28 89 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 49 8b 84 24 e0 f1 ff ff 48 8b 80 90 1b 00 00 &lt;83&gt; 38 03 0f 84 37 fe ff ff bb ea ff ff ff eb cc 49 8b 84 24 10 f3All code========   0:&#x9;f7 e8                &#x9;imul   %eax   2:&#x9;d5                   &#x9;(bad)   3:&#x9;93                   &#x9;xchg   %eax,%ebx   4:&#x9;3e ea                &#x9;ds (bad)   6:&#x9;48 83 c4 28          &#x9;add    $0x28,%rsp   a:&#x9;89 d8                &#x9;mov    %ebx,%eax   c:&#x9;5b                   &#x9;pop    %rbx   d:&#x9;41 5c                &#x9;pop    %r12   f:&#x9;41 5d                &#x9;pop    %r13  11:&#x9;41 5e                &#x9;pop    %r14  13:&#x9;41 5f                &#x9;pop    %r15  15:&#x9;5d                   &#x9;pop    %rbp  16:&#x9;c3                   &#x9;retq  17:&#x9;cc                   &#x9;int3  18:&#x9;cc                   &#x9;int3  19:&#x9;cc                   &#x9;int3  1a:&#x9;cc                   &#x9;int3  1b:&#x9;49 8b 84 24 e0 f1 ff &#x9;mov    -0xe20(%r12),%rax  22:&#x9;ff  23:&#x9;48 8b 80 90 1b 00 00 &#x9;mov    0x1b90(%rax),%rax  2a:*&#x9;83 38 03             &#x9;cmpl   $0x3,(%rax)&#x9;&#x9;&lt;-- trapping instruction  2d:&#x9;0f 84 37 fe ff ff    &#x9;je     0xfffffffffffffe6a  33:&#x9;bb ea ff ff ff       &#x9;mov    $0xffffffea,%ebx  38:&#x9;eb cc                &#x9;jmp    0x6  3a:&#x9;49                   &#x9;rex.WB  3b:&#x9;8b                   &#x9;.byte 0x8b  3c:&#x9;84 24 10             &#x9;test   %ah,(%rax,%rdx,1)  3f:&#x9;f3                   &#x9;repzCode starting with the faulting instruction===========================================   0:&#x9;83 38 03             &#x9;cmpl   $0x3,(%rax)   3:&#x9;0f 84 37 fe ff ff    &#x9;je     0xfffffffffffffe40   9:&#x9;bb ea ff ff ff       &#x9;mov    $0xffffffea,%ebx   e:&#x9;eb cc                &#x9;jmp    0xffffffffffffffdc  10:&#x9;49                   &#x9;rex.WB  11:&#x9;8b                   &#x9;.byte 0x8b  12:&#x9;84 24 10             &#x9;test   %ah,(%rax,%rdx,1)  15:&#x9;f3                   &#x9;repz[ 9890.526285] RSP: 0018:ffffb8db09013d68 EFLAGS: 00010246[ 9890.526291] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9308e0d656c8[ 9890.526295] RDX: 0000000000000000 RSI: ffffffffab99460b RDI: ffffffffab9a7685[ 9890.526300] RBP: ffffb8db09013db8 R08: 0000000000000000 R09: 0000000000000873[ 9890.526304] R10: ffff9308e0d64800 R11: 0000000000000002 R12: ffff9308e5ff6e70[ 9890.526308] R13: ffff930952500e20 R14: ffff9309192a8c00 R15: 0000000000000000[ 9890.526313] FS:  0000000000000000(0000) GS:ffff930b4e700000(0000) knlGS:0000000000000000[ 9890.526316] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 9890.526318] CR2: 0000000000000000 CR3: 0000000391c58005 CR4: 00000000001706f0[ 9890.526321] Call Trace:[ 9890.526324]  &lt;TASK&gt;[ 9890.526327] ? show_regs (arch/x86/kernel/dumpstack.c:479)[ 9890.526335] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434)[ 9890.526340] ? page_fault_oops (arch/x86/mm/fault.c:713)[ 9890.526347] ? search_module_extables (kernel/module/main.c:3256 (discriminator---truncated---(CVE-2024-43911)In the Linux kernel, the following vulnerability has been resolved:staging: iio: frequency: ad9834: Validate frequency parameter valueIn ad9834_write_frequency() clk_get_rate() can return 0. In such casead9834_calc_freqreg() call will lead to division by zero. Checking&#39;if (fout &gt; (clk_freq / 2))&#39; doesn&#39;t protect in case of &#39;fout&#39; is 0.ad9834_write_frequency() is called from ad9834_write(), where fout istaken from text buffer, which can contain any value.Modify parameters checking.Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-47663)In the Linux kernel, the following vulnerability has been resolved:scsi: pm80xx: Set phy-&gt;enable_completion only when we wait for itpm8001_phy_control() populates the enable_completion pointer with a stackaddress, sends a PHY_LINK_RESET / PHY_HARD_RESET, waits 300 ms, andreturns. The problem arises when a phy control response comes late.  After300 ms the pm8001_phy_control() function returns and the passedenable_completion stack address is no longer valid. Late phy controlresponse invokes complete() on a dangling enable_completion pointer whichleads to a kernel crash.(CVE-2024-47666)In the Linux kernel, the following vulnerability has been resolved:  bpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error  For all non-tracing helpers which formerly had ARG_PTR_TO_{LONG,INT} as input arguments, zero the value for the case of an error as otherwise it could leak memory. For tracing, it is not needed given CAP_PERFMON can already read all kernel memory anyway hence bpf_get_func_arg() and bpf_get_func_ret() is skipped in here.  Also, the MTU helpers mtu_len pointer value is being written but also read. Technically, the MEM_UNINIT should not be there in order to always force init. Removing MEM_UNINIT needs more verifier rework though: MEM_UNINIT right now implies two things actually: i) write into memory, ii) memory does not have to be initialized. If we lift MEM_UNINIT, it then becomes: i) read into memory, ii) memory must be initialized. This means that for bpf_*_check_mtu() we&#39;re readding the issue we&#39;re trying to fix, that is, it would then be able to write back into things like .rodata BPF maps. Follow-up work will rework the MEM_UNINIT semantics such that the intent can be better expressed. For now just clear the *mtu_len on error path which can be lifted later again.(CVE-2024-47728)In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Add null check for pipe_ctx-&gt;plane_state in dcn20_program_pipe  This commit addresses a null pointer dereference issue in the `dcn20_program_pipe` function. The issue could occur when `pipe_ctx-&gt;plane_state` is null.  The fix adds a check to ensure `pipe_ctx-&gt;plane_state` is not null before accessing. This prevents a null pointer dereference.  Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn20/dcn20_hwseq.c:1925 dcn20_program_pipe() error: we previously assumed &#39;pipe_ctx-&gt;plane_state&#39; could be null (see line 1877)(CVE-2024-49914)In the Linux kernel, the following vulnerability has been resolved:  net/ncsi: Disable the ncsi work before freeing the associated structure  The work function can run after the ncsi device is freed, resulting in use-after-free bugs or kernel panic.(CVE-2024-49945)In the Linux kernel, the following vulnerability has been resolved:  mailbox: bcm2835: Fix timeout during suspend mode  During noirq suspend phase the Raspberry Pi power driver suffer of firmware property timeouts. The reason is that the IRQ of the underlying BCM2835 mailbox is disabled and rpi_firmware_property_list() will always run into a timeout [1].  Since the VideoCore side isn&#39;t consider as a wakeup source, set the IRQF_NO_SUSPEND flag for the mailbox IRQ in order to keep it enabled during suspend-resume cycle.  [1] PM: late suspend of devices complete after 1.754 msecs WARNING: CPU: 0 PID: 438 at drivers/firmware/raspberrypi.c:128  rpi_firmware_property_list+0x204/0x22c Firmware transaction 0x00028001 timeout Modules linked in: CPU: 0 PID: 438 Comm: bash Tainted: G         C         6.9.3-dirty #17 Hardware name: BCM2835 Call trace: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x34/0x44 dump_stack_lvl from __warn+0x88/0xec __warn from warn_slowpath_fmt+0x7c/0xb0 warn_slowpath_fmt from rpi_firmware_property_list+0x204/0x22c rpi_firmware_property_list from rpi_firmware_property+0x68/0x8c rpi_firmware_property from rpi_firmware_set_power+0x54/0xc0 rpi_firmware_set_power from _genpd_power_off+0xe4/0x148 _genpd_power_off from genpd_sync_power_off+0x7c/0x11c genpd_sync_power_off from genpd_finish_suspend+0xcc/0xe0 genpd_finish_suspend from dpm_run_callback+0x78/0xd0 dpm_run_callback from device_suspend_noirq+0xc0/0x238 device_suspend_noirq from dpm_suspend_noirq+0xb0/0x168 dpm_suspend_noirq from suspend_devices_and_enter+0x1b8/0x5ac suspend_devices_and_enter from pm_suspend+0x254/0x2e4 pm_suspend from state_store+0xa8/0xd4 state_store from kernfs_fop_write_iter+0x154/0x1a0 kernfs_fop_write_iter from vfs_write+0x12c/0x184 vfs_write from ksys_write+0x78/0xc0 ksys_write from ret_fast_syscall+0x0/0x54 Exception stack(0xcc93dfa8 to 0xcc93dff0) [...] PM: noirq suspend of devices complete after 3095.584 msecs(CVE-2024-49963)In the Linux kernel, the following vulnerability has been resolved:  aoe: fix the potential use-after-free problem in more places  For fixing CVE-2023-6270, f98364e92662 (&#34;aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts&#34;) makes tx() calling dev_put() instead of doing in aoecmd_cfg_pkts(). It avoids that the tx() runs into use-after-free.  Then Nicolai Stange found more places in aoe have potential use-after-free problem with tx(). e.g. revalidate(), aoecmd_ata_rw(), resend(), probe() and aoecmd_cfg_rsp(). Those functions also use aoenet_xmit() to push packet to tx queue. So they should also use dev_hold() to increase the refcnt of skb-&gt;dev.  On the other hand, moving dev_put() to tx() causes that the refcnt of skb-&gt;dev be reduced to a negative value, because corresponding dev_hold() are not called in revalidate(), aoecmd_ata_rw(), resend(), probe(), and aoecmd_cfg_rsp(). This patch fixed this issue.(CVE-2024-49982)In the Linux kernel, the following vulnerability has been resolved:  KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory  Ignore nCR3[4:0] when loading PDPTEs from memory for nested SVM, as bits 4:0 of CR3 are ignored when PAE paging is used, and thus VMRUN doesn&#39;t enforce 32-byte alignment of nCR3.  In the absolute worst case scenario, failure to ignore bits 4:0 can result in an out-of-bounds read, e.g. if the target page is at the end of a memslot, and the VMM isn&#39;t using guard pages.  Per the APM:    The CR3 register points to the base address of the page-directory-pointer   table. The page-directory-pointer table is aligned on a 32-byte boundary,   with the low 5 address bits 4:0 assumed to be 0.  And the SDM&#39;s much more explicit:    4:0    Ignored  Note, KVM gets this right when loading PDPTRs, it&#39;s only the nSVM flow that is broken.(CVE-2024-50115)In the Linux kernel, the following vulnerability has been resolved:  bpf: Use raw_spinlock_t in ringbuf  The function __bpf_ringbuf_reserve is invoked from a tracepoint, which disables preemption. Using spinlock_t in this context can lead to a &#34;sleep in atomic&#34; warning in the RT variant. This issue is illustrated in the example below:  BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 556208, name: test_progs preempt_count: 1, expected: 0 RCU nest depth: 1, expected: 1 INFO: lockdep is turned off. Preemption disabled at: [&lt;ffffd33a5c88ea44&gt;] migrate_enable+0xc0/0x39c CPU: 7 PID: 556208 Comm: test_progs Tainted: G Hardware name: Qualcomm SA8775P Ride (DT) Call trace:  dump_backtrace+0xac/0x130  show_stack+0x1c/0x30  dump_stack_lvl+0xac/0xe8  dump_stack+0x18/0x30  __might_resched+0x3bc/0x4fc  rt_spin_lock+0x8c/0x1a4  __bpf_ringbuf_reserve+0xc4/0x254  bpf_ringbuf_reserve_dynptr+0x5c/0xdc  bpf_prog_ac3d15160d62622a_test_read_write+0x104/0x238  trace_call_bpf+0x238/0x774  perf_call_bpf_enter.isra.0+0x104/0x194  perf_syscall_enter+0x2f8/0x510  trace_sys_enter+0x39c/0x564  syscall_trace_enter+0x220/0x3c0  do_el0_svc+0x138/0x1dc  el0_svc+0x54/0x130  el0t_64_sync_handler+0x134/0x150  el0t_64_sync+0x17c/0x180  Switch the spinlock to raw_spinlock_t to avoid this error.(CVE-2024-50138)(CVE-2024-50151)In the Linux kernel, the following vulnerability has been resolved:  scsi: target: core: Fix null-ptr-deref in target_alloc_device()  There is a null-ptr-deref issue reported by KASAN:  BUG: KASAN: null-ptr-deref in target_alloc_device+0xbc4/0xbe0 [target_core_mod] ...  kasan_report+0xb9/0xf0  target_alloc_device+0xbc4/0xbe0 [target_core_mod]  core_dev_setup_virtual_lun0+0xef/0x1f0 [target_core_mod]  target_core_init_configfs+0x205/0x420 [target_core_mod]  do_one_initcall+0xdd/0x4e0 ...  entry_SYSCALL_64_after_hwframe+0x76/0x7e  In target_alloc_device(), if allocing memory for dev queues fails, then dev will be freed by dev-&gt;transport-&gt;free_device(), but dev-&gt;transport is not initialized at that time, which will lead to a null pointer reference problem.  Fixing this bug by freeing dev with hba-&gt;backend-&gt;ops-&gt;free_device().(CVE-2024-50153)In the Linux kernel, the following vulnerability has been resolved:  iio: light: veml6030: fix IIO device retrieval from embedded device  The dev pointer that is received as an argument in the in_illuminance_period_available_show function references the device embedded in the IIO device, not in the i2c client.  dev_to_iio_dev() must be used to accessthe right data. The current implementation leads to a segmentation fault on every attempt to read the attribute because indio_dev gets a NULL assignment.  This bug has been present since the first appearance of the driver, apparently since the last version (V6) before getting applied. A constant attribute was used until then, and the last modifications might have not been tested again.(CVE-2024-50198)In the Linux kernel, the following vulnerability has been resolved:  bpf, arm64: Fix address emission with tag-based KASAN enabled  When BPF_TRAMP_F_CALL_ORIG is enabled, the address of a bpf_tramp_image struct on the stack is passed during the size calculation pass and an address on the heap is passed during code generation. This may cause a heap buffer overflow if the heap address is tagged because emit_a64_mov_i64() will emit longer code than it did during the size calculation pass. The same problem could occur without tag-based KASAN if one of the 16-bit words of the stack address happened to be all-ones during the size calculation pass. Fix the problem by assuming the worst case (4 instructions) when calculating the size of the bpf_tramp_image address emission.(CVE-2024-50203)In the Linux kernel, the following vulnerability has been resolved:  wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower  Avoid potentially crashing in the driver because of uninitialized private data(CVE-2024-50237)In the Linux kernel, the following vulnerability has been resolved:  fs/ntfs3: Additional check in ntfs_file_release(CVE-2024-50242)In the Linux kernel, the following vulnerability has been resolved:  fs/ntfs3: Additional check in ni_clear()  Checking of NTFS_FLAGS_LOG_REPLAYING added to prevent access to uninitialized bitmap during replay process.(CVE-2024-50244)In the Linux kernel, the following vulnerability has been resolved:  fs/ntfs3: Fix possible deadlock in mi_read  Mutex lock with another subclass used in ni_lock_dir().(CVE-2024-50245)In the Linux kernel, the following vulnerability has been resolved:  fs/ntfs3: Add rough attr alloc_size check(CVE-2024-50246)In the Linux kernel, the following vulnerability has been resolved:  fs/ntfs3: Check if more than chunk-size bytes are written  A incorrectly formatted chunk may decompress into more than LZNT_CHUNK_SIZE bytes and a index out of bounds will occur in s_max_off.(CVE-2024-50247)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="bpftool" release="237.0.0.136.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-237.0.0.136.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="237.0.0.136.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-237.0.0.136.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="237.0.0.136.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-237.0.0.136.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="237.0.0.136.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-237.0.0.136.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="237.0.0.136.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-237.0.0.136.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="237.0.0.136.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-237.0.0.136.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="237.0.0.136.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-237.0.0.136.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="237.0.0.136.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-237.0.0.136.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="237.0.0.136.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-237.0.0.136.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="237.0.0.136.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-237.0.0.136.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="237.0.0.136.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-237.0.0.136.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="237.0.0.136.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-237.0.0.136.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="237.0.0.136.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-237.0.0.136.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="237.0.0.136.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-237.0.0.136.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="237.0.0.136.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-237.0.0.136.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="237.0.0.136.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-237.0.0.136.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="237.0.0.136.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-237.0.0.136.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="237.0.0.136.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-237.0.0.136.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="237.0.0.136.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-237.0.0.136.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="237.0.0.136.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-237.0.0.136.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="237.0.0.136.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-237.0.0.136.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="237.0.0.136.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-237.0.0.136.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="237.0.0.136.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-237.0.0.136.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="237.0.0.136.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-237.0.0.136.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="237.0.0.136.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-237.0.0.136.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="237.0.0.136.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-237.0.0.136.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="237.0.0.136.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-237.0.0.136.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="237.0.0.136.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-237.0.0.136.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="237.0.0.136.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-237.0.0.136.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="237.0.0.136.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-237.0.0.136.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2452</id>
          <title>An update for openjdk-11 is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-11-22"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21208" id="CVE-2024-21208" title="CVE-2024-21208" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21210" id="CVE-2024-21210" title="CVE-2024-21210" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21211" id="CVE-2024-21211" title="CVE-2024-21211" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21217" id="CVE-2024-21217" title="CVE-2024-21217" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21235" id="CVE-2024-21235" title="CVE-2024-21235" type="cve"></reference>
          </references>
          <description>Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Networking).  Supported versions that are affected are Oracle Java SE: 8u421, 8u421-perf, 11.0.24, 17.0.12, 21.0.4, 23; Oracle GraalVM for JDK: 17.0.12, 21.0.4, 23; Oracle GraalVM Enterprise Edition: 20.3.15 and  21.3.11. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 3.7 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).(CVE-2024-21208)Vulnerability in Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u421, 8u421-perf, 11.0.24, 17.0.12, 21.0.4 and  23. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).(CVE-2024-21210)Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Compiler).  Supported versions that are affected are Oracle Java SE: 23; Oracle GraalVM for JDK: 17.0.12, 21.0.4, 23; Oracle GraalVM Enterprise Edition: 20.3.15 and  21.3.11. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).(CVE-2024-21211)Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Serialization).  Supported versions that are affected are Oracle Java SE: 8u421, 8u421-perf, 11.0.24, 17.0.12, 21.0.4, 23; Oracle GraalVM for JDK: 17.0.12, 21.0.4, 23; Oracle GraalVM Enterprise Edition: 20.3.15 and  21.3.11. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).(CVE-2024-21217)Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u421, 8u421-perf, 11.0.24, 17.0.12, 21.0.4, 23;   Oracle GraalVM for JDK: 17.0.12, 21.0.4, 23;   Oracle GraalVM Enterprise Edition: 20.3.15 and  21.3.11. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as  unauthorized read access to a subset of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 4.8 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N).(CVE-2024-21235)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk" release="3.oe2203sp4" version="11.0.25.9">
                         <filename>java-11-openjdk-11.0.25.9-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-debuginfo" release="3.oe2203sp4" version="11.0.25.9">
                         <filename>java-11-openjdk-debuginfo-11.0.25.9-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-debugsource" release="3.oe2203sp4" version="11.0.25.9">
                         <filename>java-11-openjdk-debugsource-11.0.25.9-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-demo" release="3.oe2203sp4" version="11.0.25.9">
                         <filename>java-11-openjdk-demo-11.0.25.9-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-demo-slowdebug" release="3.oe2203sp4" version="11.0.25.9">
                         <filename>java-11-openjdk-demo-slowdebug-11.0.25.9-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-devel" release="3.oe2203sp4" version="11.0.25.9">
                         <filename>java-11-openjdk-devel-11.0.25.9-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-devel-slowdebug" release="3.oe2203sp4" version="11.0.25.9">
                         <filename>java-11-openjdk-devel-slowdebug-11.0.25.9-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-headless" release="3.oe2203sp4" version="11.0.25.9">
                         <filename>java-11-openjdk-headless-11.0.25.9-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-headless-slowdebug" release="3.oe2203sp4" version="11.0.25.9">
                         <filename>java-11-openjdk-headless-slowdebug-11.0.25.9-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-javadoc" release="3.oe2203sp4" version="11.0.25.9">
                         <filename>java-11-openjdk-javadoc-11.0.25.9-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-javadoc-zip" release="3.oe2203sp4" version="11.0.25.9">
                         <filename>java-11-openjdk-javadoc-zip-11.0.25.9-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-jmods" release="3.oe2203sp4" version="11.0.25.9">
                         <filename>java-11-openjdk-jmods-11.0.25.9-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-jmods-slowdebug" release="3.oe2203sp4" version="11.0.25.9">
                         <filename>java-11-openjdk-jmods-slowdebug-11.0.25.9-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-slowdebug" release="3.oe2203sp4" version="11.0.25.9">
                         <filename>java-11-openjdk-slowdebug-11.0.25.9-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-src" release="3.oe2203sp4" version="11.0.25.9">
                         <filename>java-11-openjdk-src-11.0.25.9-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-src-slowdebug" release="3.oe2203sp4" version="11.0.25.9">
                         <filename>java-11-openjdk-src-slowdebug-11.0.25.9-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk" release="3.oe2203sp4" version="11.0.25.9">
                         <filename>java-11-openjdk-11.0.25.9-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-debuginfo" release="3.oe2203sp4" version="11.0.25.9">
                         <filename>java-11-openjdk-debuginfo-11.0.25.9-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-debugsource" release="3.oe2203sp4" version="11.0.25.9">
                         <filename>java-11-openjdk-debugsource-11.0.25.9-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-demo" release="3.oe2203sp4" version="11.0.25.9">
                         <filename>java-11-openjdk-demo-11.0.25.9-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-demo-slowdebug" release="3.oe2203sp4" version="11.0.25.9">
                         <filename>java-11-openjdk-demo-slowdebug-11.0.25.9-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-devel" release="3.oe2203sp4" version="11.0.25.9">
                         <filename>java-11-openjdk-devel-11.0.25.9-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-devel-slowdebug" release="3.oe2203sp4" version="11.0.25.9">
                         <filename>java-11-openjdk-devel-slowdebug-11.0.25.9-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-headless" release="3.oe2203sp4" version="11.0.25.9">
                         <filename>java-11-openjdk-headless-11.0.25.9-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-headless-slowdebug" release="3.oe2203sp4" version="11.0.25.9">
                         <filename>java-11-openjdk-headless-slowdebug-11.0.25.9-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-javadoc" release="3.oe2203sp4" version="11.0.25.9">
                         <filename>java-11-openjdk-javadoc-11.0.25.9-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-javadoc-zip" release="3.oe2203sp4" version="11.0.25.9">
                         <filename>java-11-openjdk-javadoc-zip-11.0.25.9-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-jmods" release="3.oe2203sp4" version="11.0.25.9">
                         <filename>java-11-openjdk-jmods-11.0.25.9-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-jmods-slowdebug" release="3.oe2203sp4" version="11.0.25.9">
                         <filename>java-11-openjdk-jmods-slowdebug-11.0.25.9-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-slowdebug" release="3.oe2203sp4" version="11.0.25.9">
                         <filename>java-11-openjdk-slowdebug-11.0.25.9-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-src" release="3.oe2203sp4" version="11.0.25.9">
                         <filename>java-11-openjdk-src-11.0.25.9-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-src-slowdebug" release="3.oe2203sp4" version="11.0.25.9">
                         <filename>java-11-openjdk-src-slowdebug-11.0.25.9-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2456</id>
          <title>An update for ghostscript is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-11-22"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29507" id="CVE-2024-29507" title="CVE-2024-29507" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-33871" id="CVE-2024-33871" title="CVE-2024-33871" type="cve"></reference>
          </references>
          <description>Artifex Ghostscript before 10.03.0 sometimes has a stack-based buffer overflow via the CIDFSubstPath and CIDFSubstFont parameters.(CVE-2024-29507)An issue was discovered in Artifex Ghostscript before 10.03.1. contrib/opvp/gdevopvp.c allows arbitrary code execution via a custom Driver library, exploitable via a crafted PostScript document. This occurs because the Driver parameter for opvp (and oprp) devices can have an arbitrary name for a dynamic library; this library is then loaded.(CVE-2024-33871)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="ghostscript" release="17.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-9.55.0-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ghostscript-debuginfo" release="17.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-debuginfo-9.55.0-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ghostscript-debugsource" release="17.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-debugsource-9.55.0-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ghostscript-devel" release="17.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-devel-9.55.0-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ghostscript-tools-dvipdf" release="17.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-tools-dvipdf-9.55.0-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="ghostscript-help" release="17.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-help-9.55.0-17.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript" release="17.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-9.55.0-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript-debuginfo" release="17.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-debuginfo-9.55.0-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript-debugsource" release="17.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-debugsource-9.55.0-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript-devel" release="17.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-devel-9.55.0-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript-tools-dvipdf" release="17.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-tools-dvipdf-9.55.0-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2461</id>
          <title>An update for tomcat is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-11-22"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-52318" id="CVE-2024-52318" title="CVE-2024-52318" type="cve"></reference>
          </references>
          <description>(CVE-2024-52318)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="noarch" name="tomcat" release="2.oe2203sp4" version="9.0.96">
                         <filename>tomcat-9.0.96-2.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="tomcat-help" release="2.oe2203sp4" version="9.0.96">
                         <filename>tomcat-help-9.0.96-2.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="tomcat-jsvc" release="2.oe2203sp4" version="9.0.96">
                         <filename>tomcat-jsvc-9.0.96-2.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2467</id>
          <title>An update for postgresql is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-11-22"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-10976" id="CVE-2024-10976" title="CVE-2024-10976" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-10977" id="CVE-2024-10977" title="CVE-2024-10977" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-10978" id="CVE-2024-10978" title="CVE-2024-10978" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-10979" id="CVE-2024-10979" title="CVE-2024-10979" type="cve"></reference>
          </references>
          <description>PostgreSQL is an advanced Object-Relational database management system (DBMS).The base postgresql package contains the client programs that you&#39;ll need toaccess a PostgreSQL DBMS server, as well as HTML documentation for the wholesystem.  These client programs can be located on the same machine as thePostgreSQL server, or on a remote machine that accesses a PostgreSQL serverover a network connection.  The PostgreSQL server can be found in thepostgresql-server sub-package.Security Fix(es):Incomplete tracking in PostgreSQL of tables with row security allows a reused query to view or change different rows from those intended.  CVE-2023-2455 and CVE-2016-2193 fixed most interaction between row security and user ID changes.  They missed cases where a subquery, WITH query, security invoker view, or SQL-language function references a table with a row-level security policy.  This has the same consequences as the two earlier CVEs.  That is to say, it leads to potentially incorrect policies being applied in cases where role-specific policies are used and a given query is planned under one role and then executed under other roles.  This scenario can happen under security definer functions or when a common user and query is planned initially and then re-used across multiple SET ROLEs.  Applying an incorrect policy may permit a user to complete otherwise-forbidden reads and modifications.  This affects only databases that have used CREATE POLICY to define a row security policy.  An attacker must tailor an attack to a particular application&#39;s pattern of query plan reuse, user ID changes, and role-specific row security policies.  Versions before PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21 are affected.(CVE-2024-10976)Client use of server error message in PostgreSQL allows a server not trusted under current SSL or GSS settings to furnish arbitrary non-NUL bytes to the libpq application.  For example, a man-in-the-middle attacker could send a long error message that a human or screen-scraper user of psql mistakes for valid query results.  This is probably not a concern for clients where the user interface unambiguously indicates the boundary between one error message and other text.  Versions before PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21 are affected.(CVE-2024-10977)Incorrect privilege assignment in PostgreSQL allows a less-privileged application user to view or change different rows from those intended.  An attack requires the application to use SET ROLE, SET SESSION AUTHORIZATION, or an equivalent feature.  The problem arises when an application query uses parameters from the attacker or conveys query results to the attacker.  If that query reacts to current_setting(&#39;role&#39;) or the current user ID, it may modify or return data as though the session had not used SET ROLE or SET SESSION AUTHORIZATION.  The attacker does not control which incorrect user ID applies.  Query text from less-privileged sources is not a concern here, because SET ROLE and SET SESSION AUTHORIZATION are not sandboxes for unvetted queries.  Versions before PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21 are affected.(CVE-2024-10978)Incorrect control of environment variables in PostgreSQL PL/Perl allows an unprivileged database user to change sensitive process environment variables (e.g. PATH).  That often suffices to enable arbitrary code execution, even if the attacker lacks a database server operating system user.  Versions before PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21 are affected.(CVE-2024-10979)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="postgresql" release="1.oe2203sp4" version="13.17">
                         <filename>postgresql-13.17-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-contrib" release="1.oe2203sp4" version="13.17">
                         <filename>postgresql-contrib-13.17-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-debuginfo" release="1.oe2203sp4" version="13.17">
                         <filename>postgresql-debuginfo-13.17-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-debugsource" release="1.oe2203sp4" version="13.17">
                         <filename>postgresql-debugsource-13.17-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-docs" release="1.oe2203sp4" version="13.17">
                         <filename>postgresql-docs-13.17-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-llvmjit" release="1.oe2203sp4" version="13.17">
                         <filename>postgresql-llvmjit-13.17-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-plperl" release="1.oe2203sp4" version="13.17">
                         <filename>postgresql-plperl-13.17-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-plpython3" release="1.oe2203sp4" version="13.17">
                         <filename>postgresql-plpython3-13.17-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-pltcl" release="1.oe2203sp4" version="13.17">
                         <filename>postgresql-pltcl-13.17-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-private-devel" release="1.oe2203sp4" version="13.17">
                         <filename>postgresql-private-devel-13.17-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-private-libs" release="1.oe2203sp4" version="13.17">
                         <filename>postgresql-private-libs-13.17-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-server" release="1.oe2203sp4" version="13.17">
                         <filename>postgresql-server-13.17-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-server-devel" release="1.oe2203sp4" version="13.17">
                         <filename>postgresql-server-devel-13.17-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-static" release="1.oe2203sp4" version="13.17">
                         <filename>postgresql-static-13.17-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-test" release="1.oe2203sp4" version="13.17">
                         <filename>postgresql-test-13.17-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="postgresql-test-rpm-macros" release="1.oe2203sp4" version="13.17">
                         <filename>postgresql-test-rpm-macros-13.17-1.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql" release="1.oe2203sp4" version="13.17">
                         <filename>postgresql-13.17-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-contrib" release="1.oe2203sp4" version="13.17">
                         <filename>postgresql-contrib-13.17-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-debuginfo" release="1.oe2203sp4" version="13.17">
                         <filename>postgresql-debuginfo-13.17-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-debugsource" release="1.oe2203sp4" version="13.17">
                         <filename>postgresql-debugsource-13.17-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-docs" release="1.oe2203sp4" version="13.17">
                         <filename>postgresql-docs-13.17-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-llvmjit" release="1.oe2203sp4" version="13.17">
                         <filename>postgresql-llvmjit-13.17-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-plperl" release="1.oe2203sp4" version="13.17">
                         <filename>postgresql-plperl-13.17-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-plpython3" release="1.oe2203sp4" version="13.17">
                         <filename>postgresql-plpython3-13.17-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-pltcl" release="1.oe2203sp4" version="13.17">
                         <filename>postgresql-pltcl-13.17-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-private-devel" release="1.oe2203sp4" version="13.17">
                         <filename>postgresql-private-devel-13.17-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-private-libs" release="1.oe2203sp4" version="13.17">
                         <filename>postgresql-private-libs-13.17-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-server" release="1.oe2203sp4" version="13.17">
                         <filename>postgresql-server-13.17-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-server-devel" release="1.oe2203sp4" version="13.17">
                         <filename>postgresql-server-devel-13.17-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-static" release="1.oe2203sp4" version="13.17">
                         <filename>postgresql-static-13.17-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-test" release="1.oe2203sp4" version="13.17">
                         <filename>postgresql-test-13.17-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2471</id>
          <title>An update for libsoup is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-11-22"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-52530" id="CVE-2024-52530" title="CVE-2024-52530" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-52531" id="CVE-2024-52531" title="CVE-2024-52531" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-52532" id="CVE-2024-52532" title="CVE-2024-52532" type="cve"></reference>
          </references>
          <description>GNOME libsoup before 3.6.0 allows HTTP request smuggling in some configurations because &#39;\0&#39; characters at the end of header names are ignored, i.e., a &#34;Transfer-Encoding\0: chunked&#34; header is treated the same as a &#34;Transfer-Encoding: chunked&#34; header.(CVE-2024-52530)GNOME libsoup before 3.6.1 allows a buffer overflow in applications that perform conversion to UTF-8 in soup_header_parse_param_list_strict. Input received over the network cannot trigger this.(CVE-2024-52531)GNOME libsoup before 3.6.1 has an infinite loop, and memory consumption. during the reading of certain patterns of WebSocket data from clients.(CVE-2024-52532)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libsoup" release="5.oe2203sp4" version="2.74.2">
                         <filename>libsoup-2.74.2-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libsoup-debuginfo" release="5.oe2203sp4" version="2.74.2">
                         <filename>libsoup-debuginfo-2.74.2-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libsoup-debugsource" release="5.oe2203sp4" version="2.74.2">
                         <filename>libsoup-debugsource-2.74.2-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libsoup-devel" release="5.oe2203sp4" version="2.74.2">
                         <filename>libsoup-devel-2.74.2-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="libsoup-help" release="5.oe2203sp4" version="2.74.2">
                         <filename>libsoup-help-2.74.2-5.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libsoup" release="5.oe2203sp4" version="2.74.2">
                         <filename>libsoup-2.74.2-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libsoup-debuginfo" release="5.oe2203sp4" version="2.74.2">
                         <filename>libsoup-debuginfo-2.74.2-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libsoup-debugsource" release="5.oe2203sp4" version="2.74.2">
                         <filename>libsoup-debugsource-2.74.2-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libsoup-devel" release="5.oe2203sp4" version="2.74.2">
                         <filename>libsoup-devel-2.74.2-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2472</id>
          <title>An update for curl is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-11-22"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-9681" id="CVE-2024-9681" title="CVE-2024-9681" type="cve"></reference>
          </references>
          <description>When curl is asked to use HSTS, the expiry time for a subdomain might overwrite a parent domain&#39;s cache entry, making it end sooner or later than otherwise intended.  This affects curl using applications that enable HSTS and use URLs with the insecure `HTTP://` scheme and perform transfers with hosts like `x.example.com` as well as `example.com` where the first host is a subdomain of the second host.  (The HSTS cache either needs to have been populated manually or there needs to have been previous HTTPS accesses done as the cache needs to have entries for the domains involved to trigger this problem.)  When `x.example.com` responds with `Strict-Transport-Security:` headers, this bug can make the subdomain&#39;s expiry timeout *bleed over* and get set for the parent domain `example.com` in curl&#39;s HSTS cache.  The result of a triggered bug is that HTTP accesses to `example.com` get converted to HTTPS for a different period of time than what was asked for by the origin server. If `example.com` for example stops supporting HTTPS at its expiry time, curl might then fail to access `http://example.com` until the (wrongly set) timeout expires. This bug can also expire the parent&#39;s entry *earlier*, thus making curl inadvertently switch back to insecure HTTP earlier than otherwise intended.(CVE-2024-9681)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="curl" release="33.oe2203sp4" version="7.79.1">
                         <filename>curl-7.79.1-33.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="curl-debuginfo" release="33.oe2203sp4" version="7.79.1">
                         <filename>curl-debuginfo-7.79.1-33.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="curl-debugsource" release="33.oe2203sp4" version="7.79.1">
                         <filename>curl-debugsource-7.79.1-33.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libcurl" release="33.oe2203sp4" version="7.79.1">
                         <filename>libcurl-7.79.1-33.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libcurl-devel" release="33.oe2203sp4" version="7.79.1">
                         <filename>libcurl-devel-7.79.1-33.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="curl-help" release="33.oe2203sp4" version="7.79.1">
                         <filename>curl-help-7.79.1-33.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="curl" release="33.oe2203sp4" version="7.79.1">
                         <filename>curl-7.79.1-33.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="curl-debuginfo" release="33.oe2203sp4" version="7.79.1">
                         <filename>curl-debuginfo-7.79.1-33.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="curl-debugsource" release="33.oe2203sp4" version="7.79.1">
                         <filename>curl-debugsource-7.79.1-33.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libcurl" release="33.oe2203sp4" version="7.79.1">
                         <filename>libcurl-7.79.1-33.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libcurl-devel" release="33.oe2203sp4" version="7.79.1">
                         <filename>libcurl-devel-7.79.1-33.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2476</id>
          <title>An update for rubygem-sinatra is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-11-22"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45442" id="CVE-2022-45442" title="CVE-2022-45442" type="cve"></reference>
          </references>
          <description>Sinatra is a domain-specific language for creating web applications in Ruby. An issue was discovered in Sinatra 2.0 before 2.2.3 and 3.0 before 3.0.4. An application is vulnerable to a reflected file download (RFD) attack that sets the Content-Disposition header of a response when the filename is derived from user-supplied input. Version 2.2.3 and 3.0.4 contain patches for this issue.(CVE-2022-45442)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="noarch" name="rubygem-sinatra" release="3.oe2203sp4" version="2.0.8.1">
                         <filename>rubygem-sinatra-2.0.8.1-3.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="rubygem-sinatra-help" release="3.oe2203sp4" version="2.0.8.1">
                         <filename>rubygem-sinatra-help-2.0.8.1-3.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2478</id>
          <title>An update for php is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2024-11-29"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-11233" id="CVE-2024-11233" title="CVE-2024-11233" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-11234" id="CVE-2024-11234" title="CVE-2024-11234" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-11236" id="CVE-2024-11236" title="CVE-2024-11236" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-8929" id="CVE-2024-8929" title="CVE-2024-8929" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-8932" id="CVE-2024-8932" title="CVE-2024-8932" type="cve"></reference>
          </references>
          <description>(CVE-2024-11233)(CVE-2024-11234)(CVE-2024-11236)(CVE-2024-8929)(CVE-2024-8932)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="php" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-8.0.30-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-bcmath" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-bcmath-8.0.30-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-cli" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-cli-8.0.30-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-common" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-common-8.0.30-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-dba" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-dba-8.0.30-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-dbg" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-dbg-8.0.30-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-debuginfo" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-debuginfo-8.0.30-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-debugsource" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-debugsource-8.0.30-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-devel" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-devel-8.0.30-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-embedded" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-embedded-8.0.30-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-enchant" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-enchant-8.0.30-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-ffi" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-ffi-8.0.30-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-fpm" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-fpm-8.0.30-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-gd" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-gd-8.0.30-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-gmp" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-gmp-8.0.30-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-help" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-help-8.0.30-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-intl" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-intl-8.0.30-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-ldap" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-ldap-8.0.30-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-mbstring" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-mbstring-8.0.30-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-mysqlnd" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-mysqlnd-8.0.30-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-odbc" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-odbc-8.0.30-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-opcache" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-opcache-8.0.30-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-pdo" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-pdo-8.0.30-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-pgsql" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-pgsql-8.0.30-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-process" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-process-8.0.30-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-snmp" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-snmp-8.0.30-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-soap" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-soap-8.0.30-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-sodium" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-sodium-8.0.30-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-tidy" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-tidy-8.0.30-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-xml" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-xml-8.0.30-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-8.0.30-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-bcmath" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-bcmath-8.0.30-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-cli" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-cli-8.0.30-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-common" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-common-8.0.30-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-dba" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-dba-8.0.30-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-dbg" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-dbg-8.0.30-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-debuginfo" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-debuginfo-8.0.30-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-debugsource" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-debugsource-8.0.30-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-devel" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-devel-8.0.30-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-embedded" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-embedded-8.0.30-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-enchant" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-enchant-8.0.30-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-ffi" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-ffi-8.0.30-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-fpm" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-fpm-8.0.30-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-gd" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-gd-8.0.30-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-gmp" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-gmp-8.0.30-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-help" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-help-8.0.30-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-intl" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-intl-8.0.30-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-ldap" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-ldap-8.0.30-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-mbstring" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-mbstring-8.0.30-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-mysqlnd" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-mysqlnd-8.0.30-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-odbc" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-odbc-8.0.30-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-opcache" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-opcache-8.0.30-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-pdo" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-pdo-8.0.30-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-pgsql" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-pgsql-8.0.30-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-process" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-process-8.0.30-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-snmp" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-snmp-8.0.30-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-soap" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-soap-8.0.30-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-sodium" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-sodium-8.0.30-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-tidy" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-tidy-8.0.30-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-xml" release="7.oe2203sp4" version="8.0.30">
                         <filename>php-xml-8.0.30-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2482</id>
          <title>An update for python3 is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-11-29"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-9287" id="CVE-2024-9287" title="CVE-2024-9287" type="cve"></reference>
          </references>
          <description>A vulnerability has been found in the CPython `venv` module and CLI where path names provided when creating a virtual environment were not quoted properly, allowing the creator to inject commands into virtual environment &#34;activation&#34; scripts (ie &#34;source venv/bin/activate&#34;). This means that attacker-controlled virtual environments are able to run commands when the virtual environment is activated. Virtual environments which are not created by an attacker or which aren&#39;t activated before being used (ie &#34;./venv/bin/python&#34;) are not affected.(CVE-2024-9287)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="python3" release="38.oe2203sp4" version="3.9.9">
                         <filename>python3-3.9.9-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-debug" release="38.oe2203sp4" version="3.9.9">
                         <filename>python3-debug-3.9.9-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-debuginfo" release="38.oe2203sp4" version="3.9.9">
                         <filename>python3-debuginfo-3.9.9-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-debugsource" release="38.oe2203sp4" version="3.9.9">
                         <filename>python3-debugsource-3.9.9-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-devel" release="38.oe2203sp4" version="3.9.9">
                         <filename>python3-devel-3.9.9-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-unversioned-command" release="38.oe2203sp4" version="3.9.9">
                         <filename>python3-unversioned-command-3.9.9-38.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-help" release="38.oe2203sp4" version="3.9.9">
                         <filename>python3-help-3.9.9-38.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3" release="38.oe2203sp4" version="3.9.9">
                         <filename>python3-3.9.9-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-debug" release="38.oe2203sp4" version="3.9.9">
                         <filename>python3-debug-3.9.9-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-debuginfo" release="38.oe2203sp4" version="3.9.9">
                         <filename>python3-debuginfo-3.9.9-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-debugsource" release="38.oe2203sp4" version="3.9.9">
                         <filename>python3-debugsource-3.9.9-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-devel" release="38.oe2203sp4" version="3.9.9">
                         <filename>python3-devel-3.9.9-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-unversioned-command" release="38.oe2203sp4" version="3.9.9">
                         <filename>python3-unversioned-command-3.9.9-38.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2489</id>
          <title>An update for openjdk-latest is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-11-29"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-14556" id="CVE-2020-14556" title="CVE-2020-14556" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-14562" id="CVE-2020-14562" title="CVE-2020-14562" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-14573" id="CVE-2020-14573" title="CVE-2020-14573" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-14577" id="CVE-2020-14577" title="CVE-2020-14577" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-14578" id="CVE-2020-14578" title="CVE-2020-14578" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-14581" id="CVE-2020-14581" title="CVE-2020-14581" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-14593" id="CVE-2020-14593" title="CVE-2020-14593" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-14621" id="CVE-2020-14621" title="CVE-2020-14621" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-14664" id="CVE-2020-14664" title="CVE-2020-14664" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22025" id="CVE-2023-22025" title="CVE-2023-22025" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22081" id="CVE-2023-22081" title="CVE-2023-22081" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-42950" id="CVE-2023-42950" title="CVE-2023-42950" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20918" id="CVE-2024-20918" title="CVE-2024-20918" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-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-20932" id="CVE-2024-20932" title="CVE-2024-20932" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20945" id="CVE-2024-20945" title="CVE-2024-20945" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20952" id="CVE-2024-20952" title="CVE-2024-20952" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20955" id="CVE-2024-20955" title="CVE-2024-20955" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21002" id="CVE-2024-21002" title="CVE-2024-21002" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21003" id="CVE-2024-21003" title="CVE-2024-21003" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21004" id="CVE-2024-21004" title="CVE-2024-21004" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21005" id="CVE-2024-21005" title="CVE-2024-21005" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21011" id="CVE-2024-21011" title="CVE-2024-21011" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-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>
               <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>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21208" id="CVE-2024-21208" title="CVE-2024-21208" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21210" id="CVE-2024-21210" title="CVE-2024-21210" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21211" id="CVE-2024-21211" title="CVE-2024-21211" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21217" id="CVE-2024-21217" title="CVE-2024-21217" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21235" id="CVE-2024-21235" title="CVE-2024-21235" type="cve"></reference>
          </references>
          <description>Vulnerability in the Java SE, Java SE Embedded product of Oracle Java SE (component: Libraries). Supported versions that are affected are Java SE: 8u251, 11.0.7 and 14.0.1; Java SE Embedded: 8u251. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Java SE, Java SE Embedded accessible data as well as unauthorized read access to a subset of Java SE, Java SE Embedded accessible data. Note: Applies to client and server deployment of Java. This vulnerability can be exploited through sandboxed Java Web Start applications and sandboxed Java applets. It can also be exploited by supplying data to APIs in the specified Component without using sandboxed Java Web Start applications or sandboxed Java applets, such as through a web service. CVSS 3.1 Base Score 4.8 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N).(CVE-2020-14556)Vulnerability in the Java SE product of Oracle Java SE (component: ImageIO). Supported versions that are affected are Java SE: 11.0.7 and 14.0.1. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Java SE. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 5.3 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L).(CVE-2020-14562)Vulnerability in the Java SE product of Oracle Java SE (component: Hotspot). Supported versions that are affected are Java SE: 11.0.7 and 14.0.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Java SE accessible data. Note: Applies to client and server deployment of Java. This vulnerability can be exploited through sandboxed Java Web Start applications and sandboxed Java applets. It can also be exploited by supplying data to APIs in the specified Component without using sandboxed Java Web Start applications or sandboxed Java applets, such as through a web service. CVSS 3.1 Base Score 3.7 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).(CVE-2020-14573)Vulnerability in the Java SE, Java SE Embedded product of Oracle Java SE (component: JSSE). Supported versions that are affected are Java SE: 7u261, 8u251, 11.0.7 and 14.0.1; Java SE Embedded: 8u251. Difficult to exploit vulnerability allows unauthenticated attacker with network access via TLS to compromise Java SE, Java SE Embedded. Successful attacks of this vulnerability can result in unauthorized read access to a subset of Java SE, Java SE Embedded accessible data. Note: Applies to client and server deployment of Java. This vulnerability can be exploited through sandboxed Java Web Start applications and sandboxed Java applets. It can also be exploited by supplying data to APIs in the specified Component without using sandboxed Java Web Start applications or sandboxed Java applets, such as through a web service. CVSS 3.1 Base Score 3.7 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N).(CVE-2020-14577)Vulnerability in the Java SE, Java SE Embedded product of Oracle Java SE (component: Libraries). Supported versions that are affected are Java SE: 7u261 and 8u251; Java SE Embedded: 8u251. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Java SE, Java SE Embedded. Note: Applies to client and server deployment of Java. This vulnerability can be exploited through sandboxed Java Web Start applications and sandboxed Java applets. It can also be exploited by supplying data to APIs in the specified Component without using sandboxed Java Web Start applications or sandboxed Java applets, such as through a web service. CVSS 3.1 Base Score 3.7 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).(CVE-2020-14578)Vulnerability in the Java SE, Java SE Embedded product of Oracle Java SE (component: 2D). Supported versions that are affected are Java SE: 8u251, 11.0.7 and 14.0.1; Java SE Embedded: 8u251. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded. Successful attacks of this vulnerability can result in unauthorized read access to a subset of Java SE, Java SE Embedded accessible data. Note: Applies to client and server deployment of Java. This vulnerability can be exploited through sandboxed Java Web Start applications and sandboxed Java applets. It can also be exploited by supplying data to APIs in the specified Component without using sandboxed Java Web Start applications or sandboxed Java applets, such as through a web service. CVSS 3.1 Base Score 3.7 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N).(CVE-2020-14581)Vulnerability in the Java SE, Java SE Embedded product of Oracle Java SE (component: 2D). Supported versions that are affected are Java SE: 7u261, 8u251, 11.0.7 and 14.0.1; Java SE Embedded: 8u251. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Java SE, Java SE Embedded, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Java SE, Java SE Embedded accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 7.4 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:N/I:H/A:N).(CVE-2020-14593)Vulnerability in the Java SE, Java SE Embedded product of Oracle Java SE (component: JAXP). Supported versions that are affected are Java SE: 7u261, 8u251, 11.0.7 and 14.0.1; Java SE Embedded: 8u251. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Java SE, Java SE Embedded accessible data. Note: This vulnerability can only be exploited by supplying data to APIs in the specified Component without using Untrusted Java Web Start applications or Untrusted Java applets, such as through a web service. CVSS 3.1 Base Score 5.3 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N).(CVE-2020-14621)Vulnerability in the Java SE product of Oracle Java SE (component: JavaFX). The supported version that is affected is Java SE: 8u251. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Java SE, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in takeover of Java SE. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 8.3 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H).(CVE-2020-14664)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)A use after free issue was addressed with improved memory management. This issue is fixed in Safari 17.2, iOS 17.2 and iPadOS 17.2, tvOS 17.2, watchOS 10.2, macOS Sonoma 14.2. Processing maliciously crafted web content may lead to arbitrary code execution.(CVE-2023-42950)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: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u391, 8u391-perf, 11.0.21, 17.0.9, 21.0.1; Oracle GraalVM for JDK: 17.0.9, 21.0.1; Oracle GraalVM Enterprise Edition: 20.3.12, 21.3.8 and  22.3.4. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized creation, deletion or modification access to critical data or all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can only be exploited by supplying data to APIs in the specified Component without using Untrusted Java Web Start applications or Untrusted Java applets, such as through a web service. CVSS 3.1 Base Score 5.9 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N).(CVE-2024-20919)Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u391, 8u391-perf, 11.0.21, 17.0.9, 21.0.1; Oracle GraalVM for JDK: 17.0.9, 21.0.1; Oracle GraalVM Enterprise Edition: 20.3.12, 21.3.8 and  22.3.4. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized 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-20921)Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JavaFX).  Supported versions that are affected are Oracle Java SE: 8u391; Oracle GraalVM Enterprise Edition: 20.3.12 and  21.3.8. Difficult to exploit vulnerability allows unauthenticated attacker with logon to the infrastructure where Oracle Java SE, Oracle GraalVM Enterprise Edition executes to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 2.5 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:N).(CVE-2024-20922)Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JavaFX).  Supported versions that are affected are Oracle Java SE: 8u391; Oracle GraalVM Enterprise Edition: 20.3.12 and  21.3.8. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in  unauthorized read access to a subset of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 3.1 (Confidentiality impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N).(CVE-2024-20923)Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JavaFX).  Supported versions that are affected are Oracle Java SE: 8u391; Oracle GraalVM Enterprise Edition: 20.3.12 and  21.3.8. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 3.1 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:N).(CVE-2024-20925)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)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: Security).  Supported versions that are affected are Oracle Java SE: 8u391, 8u391-perf, 11.0.21, 17.0.9, 21.0.1; Oracle GraalVM for JDK: 17.0.9, 21.0.1; Oracle GraalVM Enterprise Edition: 20.3.12, 21.3.8 and  22.3.4. Difficult to exploit vulnerability allows low privileged attacker with logon to the infrastructure where Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition executes to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 4.7 (Confidentiality impacts).  CVSS Vector: (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N).(CVE-2024-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)Vulnerability in the Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Compiler).  Supported versions that are affected are Oracle GraalVM for JDK: 17.0.9, 21.0.1; Oracle GraalVM Enterprise Edition: 20.3.12, 21.3.8 and  22.3.4. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized read access to a subset of Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. CVSS 3.1 Base Score 3.7 (Confidentiality impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N).(CVE-2024-20955)Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JavaFX).  Supported versions that are affected are Oracle Java SE: 8u401; Oracle GraalVM Enterprise Edition: 20.3.13 and  21.3.9. Difficult to exploit vulnerability allows unauthenticated attacker with logon to the infrastructure where Oracle Java SE, Oracle GraalVM Enterprise Edition executes to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 2.5 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:N).(CVE-2024-21002)Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JavaFX).  Supported versions that are affected are Oracle Java SE: 8u401; Oracle GraalVM Enterprise Edition: 20.3.13 and  21.3.9. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 3.1 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:N).(CVE-2024-21003)Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JavaFX).  Supported versions that are affected are Oracle Java SE: 8u401; Oracle GraalVM Enterprise Edition: 20.3.13 and  21.3.9. Difficult to exploit vulnerability allows unauthenticated attacker with logon to the infrastructure where Oracle Java SE, Oracle GraalVM Enterprise Edition executes to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 2.5 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:N).(CVE-2024-21004)Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JavaFX).  Supported versions that are affected are Oracle Java SE: 8u401; Oracle GraalVM Enterprise Edition: 20.3.13 and  21.3.9. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 3.1 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:N).(CVE-2024-21005)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)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)Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Networking).  Supported versions that are affected are Oracle Java SE: 8u421, 8u421-perf, 11.0.24, 17.0.12, 21.0.4, 23; Oracle GraalVM for JDK: 17.0.12, 21.0.4, 23; Oracle GraalVM Enterprise Edition: 20.3.15 and  21.3.11. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 3.7 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).(CVE-2024-21208)Vulnerability in Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u421, 8u421-perf, 11.0.24, 17.0.12, 21.0.4 and  23. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).(CVE-2024-21210)Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Compiler).  Supported versions that are affected are Oracle Java SE: 23; Oracle GraalVM for JDK: 17.0.12, 21.0.4, 23; Oracle GraalVM Enterprise Edition: 20.3.15 and  21.3.11. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).(CVE-2024-21211)Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Serialization).  Supported versions that are affected are Oracle Java SE: 8u421, 8u421-perf, 11.0.24, 17.0.12, 21.0.4, 23; Oracle GraalVM for JDK: 17.0.12, 21.0.4, 23; Oracle GraalVM Enterprise Edition: 20.3.15 and  21.3.11. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).(CVE-2024-21217)Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u421, 8u421-perf, 11.0.24, 17.0.12, 21.0.4, 23;   Oracle GraalVM for JDK: 17.0.12, 21.0.4, 23;   Oracle GraalVM Enterprise Edition: 20.3.15 and  21.3.11. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as  unauthorized read access to a subset of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 4.8 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N).(CVE-2024-21235)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="java-latest-openjdk" release="1.oe2203sp4" version="23.0.1.11">
                         <filename>java-latest-openjdk-23.0.1.11-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-latest-openjdk-demo" release="1.oe2203sp4" version="23.0.1.11">
                         <filename>java-latest-openjdk-demo-23.0.1.11-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-latest-openjdk-demo-slowdebug" release="1.oe2203sp4" version="23.0.1.11">
                         <filename>java-latest-openjdk-demo-slowdebug-23.0.1.11-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-latest-openjdk-devel" release="1.oe2203sp4" version="23.0.1.11">
                         <filename>java-latest-openjdk-devel-23.0.1.11-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-latest-openjdk-devel-slowdebug" release="1.oe2203sp4" version="23.0.1.11">
                         <filename>java-latest-openjdk-devel-slowdebug-23.0.1.11-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-latest-openjdk-headless" release="1.oe2203sp4" version="23.0.1.11">
                         <filename>java-latest-openjdk-headless-23.0.1.11-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-latest-openjdk-headless-slowdebug" release="1.oe2203sp4" version="23.0.1.11">
                         <filename>java-latest-openjdk-headless-slowdebug-23.0.1.11-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-latest-openjdk-javadoc" release="1.oe2203sp4" version="23.0.1.11">
                         <filename>java-latest-openjdk-javadoc-23.0.1.11-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-latest-openjdk-javadoc-zip" release="1.oe2203sp4" version="23.0.1.11">
                         <filename>java-latest-openjdk-javadoc-zip-23.0.1.11-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-latest-openjdk-jmods" release="1.oe2203sp4" version="23.0.1.11">
                         <filename>java-latest-openjdk-jmods-23.0.1.11-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-latest-openjdk-jmods-slowdebug" release="1.oe2203sp4" version="23.0.1.11">
                         <filename>java-latest-openjdk-jmods-slowdebug-23.0.1.11-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-latest-openjdk-slowdebug" release="1.oe2203sp4" version="23.0.1.11">
                         <filename>java-latest-openjdk-slowdebug-23.0.1.11-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-latest-openjdk-src" release="1.oe2203sp4" version="23.0.1.11">
                         <filename>java-latest-openjdk-src-23.0.1.11-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-latest-openjdk-src-slowdebug" release="1.oe2203sp4" version="23.0.1.11">
                         <filename>java-latest-openjdk-src-slowdebug-23.0.1.11-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-latest-openjdk" release="1.oe2203sp4" version="23.0.1.11">
                         <filename>java-latest-openjdk-23.0.1.11-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-latest-openjdk-demo" release="1.oe2203sp4" version="23.0.1.11">
                         <filename>java-latest-openjdk-demo-23.0.1.11-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-latest-openjdk-demo-slowdebug" release="1.oe2203sp4" version="23.0.1.11">
                         <filename>java-latest-openjdk-demo-slowdebug-23.0.1.11-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-latest-openjdk-devel" release="1.oe2203sp4" version="23.0.1.11">
                         <filename>java-latest-openjdk-devel-23.0.1.11-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-latest-openjdk-devel-slowdebug" release="1.oe2203sp4" version="23.0.1.11">
                         <filename>java-latest-openjdk-devel-slowdebug-23.0.1.11-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-latest-openjdk-headless" release="1.oe2203sp4" version="23.0.1.11">
                         <filename>java-latest-openjdk-headless-23.0.1.11-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-latest-openjdk-headless-slowdebug" release="1.oe2203sp4" version="23.0.1.11">
                         <filename>java-latest-openjdk-headless-slowdebug-23.0.1.11-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-latest-openjdk-javadoc" release="1.oe2203sp4" version="23.0.1.11">
                         <filename>java-latest-openjdk-javadoc-23.0.1.11-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-latest-openjdk-javadoc-zip" release="1.oe2203sp4" version="23.0.1.11">
                         <filename>java-latest-openjdk-javadoc-zip-23.0.1.11-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-latest-openjdk-jmods" release="1.oe2203sp4" version="23.0.1.11">
                         <filename>java-latest-openjdk-jmods-23.0.1.11-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-latest-openjdk-jmods-slowdebug" release="1.oe2203sp4" version="23.0.1.11">
                         <filename>java-latest-openjdk-jmods-slowdebug-23.0.1.11-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-latest-openjdk-slowdebug" release="1.oe2203sp4" version="23.0.1.11">
                         <filename>java-latest-openjdk-slowdebug-23.0.1.11-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-latest-openjdk-src" release="1.oe2203sp4" version="23.0.1.11">
                         <filename>java-latest-openjdk-src-23.0.1.11-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-latest-openjdk-src-slowdebug" release="1.oe2203sp4" version="23.0.1.11">
                         <filename>java-latest-openjdk-src-slowdebug-23.0.1.11-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2493</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-11-29"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43817" id="CVE-2024-43817" title="CVE-2024-43817" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45018" id="CVE-2024-45018" title="CVE-2024-45018" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46713" id="CVE-2024-46713" title="CVE-2024-46713" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47745" id="CVE-2024-47745" title="CVE-2024-47745" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47747" id="CVE-2024-47747" title="CVE-2024-47747" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47749" id="CVE-2024-47749" title="CVE-2024-47749" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49899" id="CVE-2024-49899" title="CVE-2024-49899" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49929" id="CVE-2024-49929" title="CVE-2024-49929" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49952" id="CVE-2024-49952" title="CVE-2024-49952" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50045" id="CVE-2024-50045" title="CVE-2024-50045" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50062" id="CVE-2024-50062" title="CVE-2024-50062" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50085" id="CVE-2024-50085" title="CVE-2024-50085" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50089" id="CVE-2024-50089" title="CVE-2024-50089" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50141" id="CVE-2024-50141" title="CVE-2024-50141" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50143" id="CVE-2024-50143" title="CVE-2024-50143" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50179" id="CVE-2024-50179" title="CVE-2024-50179" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50180" id="CVE-2024-50180" title="CVE-2024-50180" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50192" id="CVE-2024-50192" title="CVE-2024-50192" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50195" id="CVE-2024-50195" title="CVE-2024-50195" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50202" id="CVE-2024-50202" title="CVE-2024-50202" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50205" id="CVE-2024-50205" title="CVE-2024-50205" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50229" id="CVE-2024-50229" title="CVE-2024-50229" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50230" id="CVE-2024-50230" title="CVE-2024-50230" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50241" id="CVE-2024-50241" title="CVE-2024-50241" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50248" id="CVE-2024-50248" title="CVE-2024-50248" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50262" id="CVE-2024-50262" title="CVE-2024-50262" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50265" id="CVE-2024-50265" title="CVE-2024-50265" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50269" id="CVE-2024-50269" title="CVE-2024-50269" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50273" id="CVE-2024-50273" title="CVE-2024-50273" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50289" id="CVE-2024-50289" title="CVE-2024-50289" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50301" id="CVE-2024-50301" title="CVE-2024-50301" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53052" id="CVE-2024-53052" title="CVE-2024-53052" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53061" id="CVE-2024-53061" title="CVE-2024-53061" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53066" id="CVE-2024-53066" title="CVE-2024-53066" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:net: missing check virtioTwo missing check in virtio_net_hdr_to_skb() allowed syzbotto crash kernels again1. After the skb_segment function the buffer may become non-linear(nr_frags != 0), but since the SKBTX_SHARED_FRAG flag is not set anywherethe __skb_linearize function will not be executed, then the buffer willremain non-linear. Then the condition (offset &gt;= skb_headlen(skb))becomes true, which causes WARN_ON_ONCE in skb_checksum_help.2. The struct sk_buff and struct virtio_net_hdr members must bemathematically related.(gso_size) must be greater than (needed) otherwise WARN_ON_ONCE.(remainder) must be greater than (needed) otherwise WARN_ON_ONCE.(remainder) may be 0 if division is without remainder.offset+2 (4191) &gt; skb_headlen() (1116)WARNING: CPU: 1 PID: 5084 at net/core/dev.c:3303 skb_checksum_help+0x5e2/0x740 net/core/dev.c:3303Modules linked in:CPU: 1 PID: 5084 Comm: syz-executor336 Not tainted 6.7.0-rc3-syzkaller-00014-gdf60cee26a2e #0Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023RIP: 0010:skb_checksum_help+0x5e2/0x740 net/core/dev.c:3303Code: 89 e8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 52 01 00 00 44 89 e2 2b 53 74 4c 89 ee 48 c7 c7 40 57 e9 8b e8 af 8f dd f8 90 &lt;0f&gt; 0b 90 90 e9 87 fe ff ff e8 40 0f 6e f9 e9 4b fa ff ff 48 89 efRSP: 0018:ffffc90003a9f338 EFLAGS: 00010286RAX: 0000000000000000 RBX: ffff888025125780 RCX: ffffffff814db209RDX: ffff888015393b80 RSI: ffffffff814db216 RDI: 0000000000000001RBP: ffff8880251257f4 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000045cR13: 000000000000105f R14: ffff8880251257f0 R15: 000000000000105dFS:  0000555555c24380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000000002000f000 CR3: 0000000023151000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: &lt;TASK&gt; ip_do_fragment+0xa1b/0x18b0 net/ipv4/ip_output.c:777 ip_fragment.constprop.0+0x161/0x230 net/ipv4/ip_output.c:584 ip_finish_output_gso net/ipv4/ip_output.c:286 [inline] __ip_finish_output net/ipv4/ip_output.c:308 [inline] __ip_finish_output+0x49c/0x650 net/ipv4/ip_output.c:295 ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip_output+0x13b/0x2a0 net/ipv4/ip_output.c:433 dst_output include/net/dst.h:451 [inline] ip_local_out+0xaf/0x1a0 net/ipv4/ip_output.c:129 iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82 ipip6_tunnel_xmit net/ipv6/sit.c:1034 [inline] sit_tunnel_xmit+0xed2/0x28f0 net/ipv6/sit.c:1076 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3545 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3561 __dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4346 dev_queue_xmit include/linux/netdevice.h:3134 [inline] packet_xmit+0x257/0x380 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3087 [inline] packet_sendmsg+0x24ca/0x5240 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0xd5/0x180 net/socket.c:745 __sys_sendto+0x255/0x340 net/socket.c:2190 __do_sys_sendto net/socket.c:2202 [inline] __se_sys_sendto net/socket.c:2198 [inline] __x64_sys_sendto+0xe0/0x1b0 net/socket.c:2198 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6bFound by Linux Verification Center (linuxtesting.org) with Syzkaller(CVE-2024-43817)In the Linux kernel, the following vulnerability has been resolved:netfilter: flowtable: initialise extack before useFix missing initialisation of extack in flow offload.(CVE-2024-45018)In the Linux kernel, the following vulnerability has been resolved:perf/aux: Fix AUX buffer serializationOle reported that event-&gt;mmap_mutex is strictly insufficient toserialize the AUX buffer, add a per RB mutex to fully serialize it.Note that in the lock order comment the perf_event::mmap_mutex orderwas already wrong, that is, it nesting under mmap_lock is not new withthis patch.(CVE-2024-46713)In the Linux kernel, the following vulnerability has been resolved:  mm: call the security_mmap_file() LSM hook in remap_file_pages()  The remap_file_pages syscall handler calls do_mmap() directly, which doesn&#39;t contain the LSM security check. And if the process has called personality(READ_IMPLIES_EXEC) before and remap_file_pages() is called for RW pages, this will actually result in remapping the pages to RWX, bypassing a W^X policy enforced by SELinux.  So we should check prot by security_mmap_file LSM hook in the remap_file_pages syscall handler before do_mmap() is called. Otherwise, it potentially permits an attacker to bypass a W^X policy enforced by SELinux.  The bypass is similar to CVE-2016-10044, which bypass the same thing via AIO and can be found in [1].  The PoC:  $ cat &gt; test.c  int main(void) {  size_t pagesz = sysconf(_SC_PAGE_SIZE);  int mfd = syscall(SYS_memfd_create, &#34;test&#34;, 0);  const char *buf = mmap(NULL, 4 * pagesz, PROT_READ | PROT_WRITE,   MAP_SHARED, mfd, 0);  unsigned int old = syscall(SYS_personality, 0xffffffff);  syscall(SYS_personality, READ_IMPLIES_EXEC | old);  syscall(SYS_remap_file_pages, buf, pagesz, 0, 2, 0);  syscall(SYS_personality, old);  // show the RWX page exists even if W^X policy is enforced  int fd = open(&#34;/proc/self/maps&#34;, O_RDONLY);  unsigned char buf2[1024];  while (1) {   int ret = read(fd, buf2, 1024);   if (ret &lt;= 0) break;   write(1, buf2, ret);  }  close(fd); }  $ gcc test.c -o test $ ./test | grep rwx 7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted)  [PM: subject line tweaks](CVE-2024-47745)In the Linux kernel, the following vulnerability has been resolved:  net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race Condition  In the ether3_probe function, a timer is initialized with a callback function ether3_ledoff, bound to &amp;prev(dev)-&gt;timer. Once the timer is started, there is a risk of a race condition if the module or device is removed, triggering the ether3_remove function to perform cleanup. The sequence of operations that may lead to a UAF bug is as follows:  CPU0                                    CPU1                        |  ether3_ledoff ether3_remove         |   free_netdev(dev);   |   put_devic           |   kfree(dev);         |  |  ether3_outw(priv(dev)-&gt;regs.config2 |= CFG2_CTRLO, REG_CONFIG2);                       | // use dev  Fix it by ensuring that the timer is canceled before proceeding with the cleanup in ether3_remove.(CVE-2024-47747)In the Linux kernel, the following vulnerability has been resolved:  RDMA/cxgb4: Added NULL check for lookup_atid  The lookup_atid() function can return NULL if the ATID is invalid or does not exist in the identifier table, which could lead to dereferencing a null pointer without a check in the `act_establish()` and `act_open_rpl()` functions. Add a NULL check to prevent null pointer dereferencing.  Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-47749)In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Initialize denominators&#39; default to 1  [WHAT &amp; HOW] Variables used as denominators and maybe not assigned to other values, should not be 0. Change their default to 1 so they are never 0.  This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.(CVE-2024-49899)In the Linux kernel, the following vulnerability has been resolved:  wifi: iwlwifi: mvm: avoid NULL pointer dereference  iwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvsta pointer is not NULL. It retrieves this pointer using iwl_mvm_sta_from_mac80211, which is dereferencing the ieee80211_sta pointer. If sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULL pointer. Fix this by checking the sta pointer before retrieving the mvmsta from it. If sta is not NULL, then mvmsta isn&#39;t either.(CVE-2024-49929)In the Linux kernel, the following vulnerability has been resolved:  netfilter: nf_tables: prevent nf_skb_duplicated corruption  syzbot found that nf_dup_ipv4() or nf_dup_ipv6() could write per-cpu variable nf_skb_duplicated in an unsafe way [1].  Disabling preemption as hinted by the splat is not enough, we have to disable soft interrupts as well.  [1] BUG: using __this_cpu_write() in preemptible [00000000] code: syz.4.282/6316  caller is nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 CPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 Not tainted 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace:  &lt;TASK&gt;   __dump_stack lib/dump_stack.c:93 [inline]   dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119   check_preemption_disabled+0x10e/0x120 lib/smp_processor_id.c:49   nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87   nft_dup_ipv4_eval+0x1db/0x300 net/ipv4/netfilter/nft_dup_ipv4.c:30   expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]   nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288   nft_do_chain_ipv4+0x202/0x320 net/netfilter/nft_chain_filter.c:23   nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]   nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626   nf_hook+0x2c4/0x450 include/linux/netfilter.h:269   NF_HOOK_COND include/linux/netfilter.h:302 [inline]   ip_output+0x185/0x230 net/ipv4/ip_output.c:433   ip_local_out net/ipv4/ip_output.c:129 [inline]   ip_send_skb+0x74/0x100 net/ipv4/ip_output.c:1495   udp_send_skb+0xacf/0x1650 net/ipv4/udp.c:981   udp_sendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269   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_sendmmsg+0x3b2/0x740 net/socket.c:2737   __do_sys_sendmmsg net/socket.c:2766 [inline]   __se_sys_sendmmsg net/socket.c:2763 [inline]   __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2763   do_syscall_x64 arch/x86/entry/common.c:52 [inline]   do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f4ce4f7def9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f4ce5d4a038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9 RDX: 0000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006 RBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68  &lt;/TASK&gt;(CVE-2024-49952)In the Linux kernel, the following vulnerability has been resolved:  netfilter: br_netfilter: fix panic with metadata_dst skb  Fix a kernel panic in the br_netfilter module when sending untagged traffic via a VxLAN device. This happens during the check for fragmentation in br_nf_dev_queue_xmit.  It is dependent on: 1) the br_netfilter module being loaded; 2) net.bridge.bridge-nf-call-iptables set to 1; 3) a bridge with a VxLAN (single-vxlan-device) netdevice as a bridge port; 4) untagged frames with size higher than the VxLAN MTU forwarded/flooded  When forwarding the untagged packet to the VxLAN bridge port, before the netfilter hooks are called, br_handle_egress_vlan_tunnel is called and changes the skb_dst to the tunnel dst. The tunnel_dst is a metadata type of dst, i.e., skb_valid_dst(skb) is false, and metadata-&gt;dst.dev is NULL.  Then in the br_netfilter hooks, in br_nf_dev_queue_xmit, there&#39;s a check for frames that needs to be fragmented: frames with higher MTU than the VxLAN device end up calling br_nf_ip_fragment, which in turns call ip_skb_dst_mtu.  The ip_dst_mtu tries to use the skb_dst(skb) as if it was a valid dst with valid dst-&gt;dev, thus the crash.  This case was never supported in the first place, so drop the packet instead.  PING 10.0.0.2 (10.0.0.2) from 0.0.0.0 h1-eth0: 2000(2028) bytes of data. [  176.291791] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000110 [  176.292101] Mem abort info: [  176.292184]   ESR = 0x0000000096000004 [  176.292322]   EC = 0x25: DABT (current EL), IL = 32 bits [  176.292530]   SET = 0, FnV = 0 [  176.292709]   EA = 0, S1PTW = 0 [  176.292862]   FSC = 0x04: level 0 translation fault [  176.293013] Data abort info: [  176.293104]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [  176.293488]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [  176.293787]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [  176.293995] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000043ef5000 [  176.294166] [0000000000000110] pgd=0000000000000000, p4d=0000000000000000 [  176.294827] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [  176.295252] Modules linked in: vxlan ip6_udp_tunnel udp_tunnel veth br_netfilter bridge stp llc ipv6 crct10dif_ce [  176.295923] CPU: 0 PID: 188 Comm: ping Not tainted 6.8.0-rc3-g5b3fbd61b9d1 #2 [  176.296314] Hardware name: linux,dummy-virt (DT) [  176.296535] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [  176.296808] pc : br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [  176.297382] lr : br_nf_dev_queue_xmit+0x2ac/0x4ec [br_netfilter] [  176.297636] sp : ffff800080003630 [  176.297743] x29: ffff800080003630 x28: 0000000000000008 x27: ffff6828c49ad9f8 [  176.298093] x26: ffff6828c49ad000 x25: 0000000000000000 x24: 00000000000003e8 [  176.298430] x23: 0000000000000000 x22: ffff6828c4960b40 x21: ffff6828c3b16d28 [  176.298652] x20: ffff6828c3167048 x19: ffff6828c3b16d00 x18: 0000000000000014 [  176.298926] x17: ffffb0476322f000 x16: ffffb7e164023730 x15: 0000000095744632 [  176.299296] x14: ffff6828c3f1c880 x13: 0000000000000002 x12: ffffb7e137926a70 [  176.299574] x11: 0000000000000001 x10: ffff6828c3f1c898 x9 : 0000000000000000 [  176.300049] x8 : ffff6828c49bf070 x7 : 0008460f18d5f20e x6 : f20e0100bebafeca [  176.300302] x5 : ffff6828c7f918fe x4 : ffff6828c49bf070 x3 : 0000000000000000 [  176.300586] x2 : 0000000000000000 x1 : ffff6828c3c7ad00 x0 : ffff6828c7f918f0 [  176.300889] Call trace: [  176.301123]  br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [  176.301411]  br_nf_post_routing+0x2a8/0x3e4 [br_netfilter] [  176.301703]  nf_hook_slow+0x48/0x124 [  176.302060]  br_forward_finish+0xc8/0xe8 [bridge] [  176.302371]  br_nf_hook_thresh+0x124/0x134 [br_netfilter] [  176.302605]  br_nf_forward_finish+0x118/0x22c [br_netfilter] [  176.302824]  br_nf_forward_ip.part.0+0x264/0x290 [br_netfilter] [  176.303136]  br_nf_forward+0x2b8/0x4e0 [br_netfilter] [  176.303359]  nf_hook_slow+0x48/0x124 [  176.303 ---truncated---(CVE-2024-50045)In the Linux kernel, the following vulnerability has been resolved:  RDMA/rtrs-srv: Avoid null pointer deref during path establishment  For RTRS path establishment, RTRS client initiates and completes con_num of connections. After establishing all its connections, the information is exchanged between the client and server through the info_req message. During this exchange, it is essential that all connections have been established, and the state of the RTRS srv path is CONNECTED.  So add these sanity checks, to make sure we detect and abort process in error scenarios to avoid null pointer deref.(CVE-2024-50062)In the Linux kernel, the following vulnerability has been resolved:  mptcp: pm: fix UaF read in mptcp_pm_nl_rm_addr_or_subflow  Syzkaller reported this splat:    ==================================================================   BUG: KASAN: slab-use-after-free in mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881   Read of size 4 at addr ffff8880569ac858 by task syz.1.2799/14662    CPU: 0 UID: 0 PID: 14662 Comm: syz.1.2799 Not tainted 6.12.0-rc2-syzkaller-00307-g36c254515dc6 #0   Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014   Call Trace:    &lt;TASK&gt;    __dump_stack lib/dump_stack.c:94 [inline]    dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120    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    mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881    mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:914 [inline]    mptcp_nl_remove_id_zero_address+0x305/0x4a0 net/mptcp/pm_netlink.c:1572    mptcp_pm_nl_del_addr_doit+0x5c9/0x770 net/mptcp/pm_netlink.c:1603    genl_family_rcv_msg_doit+0x202/0x2f0 net/netlink/genetlink.c:1115    genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline]    genl_rcv_msg+0x565/0x800 net/netlink/genetlink.c:1210    netlink_rcv_skb+0x165/0x410 net/netlink/af_netlink.c:2551    genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219    netlink_unicast_kernel net/netlink/af_netlink.c:1331 [inline]    netlink_unicast+0x53c/0x7f0 net/netlink/af_netlink.c:1357    netlink_sendmsg+0x8b8/0xd70 net/netlink/af_netlink.c:1901    sock_sendmsg_nosec net/socket.c:729 [inline]    __sock_sendmsg net/socket.c:744 [inline]    ____sys_sendmsg+0x9ae/0xb40 net/socket.c:2607    ___sys_sendmsg+0x135/0x1e0 net/socket.c:2661    __sys_sendmsg+0x117/0x1f0 net/socket.c:2690    do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline]    __do_fast_syscall_32+0x73/0x120 arch/x86/entry/common.c:386    do_fast_syscall_32+0x32/0x80 arch/x86/entry/common.c:411    entry_SYSENTER_compat_after_hwframe+0x84/0x8e   RIP: 0023:0xf7fe4579   Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 &lt;5d&gt; 5a 59 c3 90 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00   RSP: 002b:00000000f574556c EFLAGS: 00000296 ORIG_RAX: 0000000000000172   RAX: ffffffffffffffda RBX: 000000000000000b RCX: 0000000020000140   RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000   RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000   R10: 0000000000000000 R11: 0000000000000296 R12: 0000000000000000   R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000    &lt;/TASK&gt;    Allocated by task 5387:    kasan_save_stack+0x33/0x60 mm/kasan/common.c:47    kasan_save_track+0x14/0x30 mm/kasan/common.c:68    poison_kmalloc_redzone mm/kasan/common.c:377 [inline]    __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394    kmalloc_noprof include/linux/slab.h:878 [inline]    kzalloc_noprof include/linux/slab.h:1014 [inline]    subflow_create_ctx+0x87/0x2a0 net/mptcp/subflow.c:1803    subflow_ulp_init+0xc3/0x4d0 net/mptcp/subflow.c:1956    __tcp_set_ulp net/ipv4/tcp_ulp.c:146 [inline]    tcp_set_ulp+0x326/0x7f0 net/ipv4/tcp_ulp.c:167    mptcp_subflow_create_socket+0x4ae/0x10a0 net/mptcp/subflow.c:1764    __mptcp_subflow_connect+0x3cc/0x1490 net/mptcp/subflow.c:1592    mptcp_pm_create_subflow_or_signal_addr+0xbda/0x23a0 net/mptcp/pm_netlink.c:642    mptcp_pm_nl_fully_established net/mptcp/pm_netlink.c:650 [inline]    mptcp_pm_nl_work+0x3a1/0x4f0 net/mptcp/pm_netlink.c:943    mptcp_worker+0x15a/0x1240 net/mptcp/protocol.c:2777    process_one_work+0x958/0x1b30 kernel/workqueue.c:3229    process_scheduled_works kernel/workqueue.c:3310 [inline]    worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391    kthread+0x2c1/0x3a0 kernel/kthread.c:389    ret_from_fork+0x45/0x80 arch/x86/ke ---truncated---(CVE-2024-50085)In the Linux kernel, the following vulnerability has been resolved:  unicode: Don&#39;t special case ignorable code points  We don&#39;t need to handle them separately. Instead, just let them decompose/casefold to themselves.(CVE-2024-50089)In the Linux kernel, the following vulnerability has been resolved:  ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context  PRMT needs to find the correct type of block to translate the PA-VA mapping for EFI runtime services.  The issue arises because the PRMT is finding a block of type EFI_CONVENTIONAL_MEMORY, which is not appropriate for runtime services as described in Section 2.2.2 (Runtime Services) of the UEFI Specification [1]. Since the PRM handler is a type of runtime service, this causes an exception when the PRM handler is called.      [Firmware Bug]: Unable to handle paging request in EFI runtime service     WARNING: CPU: 22 PID: 4330 at drivers/firmware/efi/runtime-wrappers.c:341         __efi_queue_work+0x11c/0x170     Call trace:  Let PRMT find a block with EFI_MEMORY_RUNTIME for PRM handler and PRM context.  If no suitable block is found, a warning message will be printed, but the procedure continues to manage the next PRM handler.  However, if the PRM handler is actually called without proper allocation, it would result in a failure during error handling.  By using the correct memory types for runtime services, ensure that the PRM handler and the context are properly mapped in the virtual address space during runtime, preventing the paging request error.  The issue is really that only memory that has been remapped for runtime by the firmware can be used by the PRM handler, and so the region needs to have the EFI_MEMORY_RUNTIME attribute.  [ rjw: Subject and changelog edits ](CVE-2024-50141)In the Linux kernel, the following vulnerability has been resolved:  udf: fix uninit-value use in udf_get_fileshortad  Check for overflow when computing alen in udf_current_aext to mitigate later uninit-value use in udf_get_fileshortad KMSAN bug[1]. After applying the patch reproducer did not trigger any issue[2].  [1] https://syzkaller.appspot.com/bug?extid=8901c4560b7ab5c2f9df [2] https://syzkaller.appspot.com/x/log.txt?x=10242227980000(CVE-2024-50143)In the Linux kernel, the following vulnerability has been resolved:  ceph: remove the incorrect Fw reference check when dirtying pages  When doing the direct-io reads it will also try to mark pages dirty, but for the read path it won&#39;t hold the Fw caps and there is case will it get the Fw reference.(CVE-2024-50179)In the Linux kernel, the following vulnerability has been resolved:  fbdev: sisfb: Fix strbuf array overflow  The values of the variables xres and yres are placed in strbuf. These variables are obtained from strbuf1. The strbuf1 array contains digit characters and a space if the array contains non-digit characters. Then, when executing sprintf(strbuf, &#34;%ux%ux8&#34;, xres, yres); more than 16 bytes will be written to strbuf. It is suggested to increase the size of the strbuf array to 24.  Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-50180)In the Linux kernel, the following vulnerability has been resolved:  irqchip/gic-v4: Don&#39;t allow a VMOVP on a dying VPE  Kunkun Jiang reported that there is a small window of opportunity for userspace to force a change of affinity for a VPE while the VPE has already been unmapped, but the corresponding doorbell interrupt still visible in /proc/irq/.  Plug the race by checking the value of vmapp_count, which tracks whether the VPE is mapped ot not, and returning an error in this case.  This involves making vmapp_count common to both GICv4.1 and its v4.0 ancestor.(CVE-2024-50192)In the Linux kernel, the following vulnerability has been resolved:  posix-clock: Fix missing timespec64 check in pc_clock_settime()  As Andrew pointed out, it will make sense that the PTP core checked timespec64 struct&#39;s tv_sec and tv_nsec range before calling ptp-&gt;info-&gt;settime64().  As the man manual of clock_settime() said, if tp.tv_sec is negative or tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL, which include dynamic clocks which handles PTP clock, and the condition is consistent with timespec64_valid(). As Thomas suggested, timespec64_valid() only check the timespec is valid, but not ensure that the time is in a valid range, so check it ahead using timespec64_valid_strict() in pc_clock_settime() and return -EINVAL if not valid.  There are some drivers that use tp-&gt;tv_sec and tp-&gt;tv_nsec directly to write registers without validity checks and assume that the higher layer has checked it, which is dangerous and will benefit from this, such as hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(), and some drivers can remove the checks of itself.(CVE-2024-50195)In the Linux kernel, the following vulnerability has been resolved:  nilfs2: propagate directory read errors from nilfs_find_entry()  Syzbot reported that a task hang occurs in vcs_open() during a fuzzing test for nilfs2.  The root cause of this problem is that in nilfs_find_entry(), which searches for directory entries, ignores errors when loading a directory page/folio via nilfs_get_folio() fails.  If the filesystem images is corrupted, and the i_size of the directory inode is large, and the directory page/folio is successfully read but fails the sanity check, for example when it is zero-filled, nilfs_check_folio() may continue to spit out error messages in bursts.  Fix this issue by propagating the error to the callers when loading a page/folio fails in nilfs_find_entry().  The current interface of nilfs_find_entry() and its callers is outdated and cannot propagate error codes such as -EIO and -ENOMEM returned via nilfs_find_entry(), so fix it together.(CVE-2024-50202)In the Linux kernel, the following vulnerability has been resolved:  ALSA: firewire-lib: Avoid division by zero in apply_constraint_to_size()  The step variable is initialized to zero. It is changed in the loop, but if it&#39;s not changed it will remain zero. Add a variable check before the division.  The observed behavior was introduced by commit 826b5de90c0b (&#34;ALSA: firewire-lib: fix insufficient PCM rule for period/buffer size&#34;), and it is difficult to show that any of the interval parameters will satisfy the snd_interval_test() condition with data from the amdtp_rate_table[] table.  Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-50205)In the Linux kernel, the following vulnerability has been resolved:  nilfs2: fix potential deadlock with newly created symlinks  Syzbot reported that page_symlink(), called by nilfs_symlink(), triggers memory reclamation involving the filesystem layer, which can result in circular lock dependencies among the reader/writer semaphore nilfs-&gt;ns_segctor_sem, s_writers percpu_rwsem (intwrite) and the fs_reclaim pseudo lock.  This is because after commit 21fc61c73c39 (&#34;don&#39;t put symlink bodies in pagecache into highmem&#34;), the gfp flags of the page cache for symbolic links are overwritten to GFP_KERNEL via inode_nohighmem().  This is not a problem for symlinks read from the backing device, because the __GFP_FS flag is dropped after inode_nohighmem() is called.  However, when a new symlink is created with nilfs_symlink(), the gfp flags remain overwritten to GFP_KERNEL.  Then, memory allocation called from page_symlink() etc.  triggers memory reclamation including the FS layer, which may call nilfs_evict_inode() or nilfs_dirty_inode().  And these can cause a deadlock if they are called while nilfs-&gt;ns_segctor_sem is held:  Fix this issue by dropping the __GFP_FS flag from the page cache GFP flags of newly created symlinks in the same way that nilfs_new_inode() and __nilfs_read_inode() do, as a workaround until we adopt nofs allocation scope consistently or improve the locking constraints.(CVE-2024-50229)In the Linux kernel, the following vulnerability has been resolved:  nilfs2: fix kernel bug due to missing clearing of checked flag  Syzbot reported that in directory operations after nilfs2 detects filesystem corruption and degrades to read-only, __block_write_begin_int(), which is called to prepare block writes, may fail the BUG_ON check for accesses exceeding the folio/page size, triggering a kernel bug.  This was found to be because the &#34;checked&#34; flag of a page/folio was not cleared when it was discarded by nilfs2&#39;s own routine, which causes the sanity check of directory entries to be skipped when the directory page/folio is reloaded.  So, fix that.  This was necessary when the use of nilfs2&#39;s own page discard routine was applied to more than just metadata files.(CVE-2024-50230)In the Linux kernel, the following vulnerability has been resolved:  NFSD: Initialize struct nfsd4_copy earlier  Ensure the refcount and async_copies fields are initialized early. cleanup_async_copy() will reference these fields if an error occurs in nfsd4_copy(). If they are not correctly initialized, at the very least, a refcount underflow occurs.(CVE-2024-50241)In the Linux kernel, the following vulnerability has been resolved:  ntfs3: Add bounds checking to mi_enum_attr()  Added bounds checking to make sure that every attr don&#39;t stray beyond valid memory region.(CVE-2024-50248)In the Linux kernel, the following vulnerability has been resolved:  bpf: Fix out-of-bounds write in trie_get_next_key()  trie_get_next_key() allocates a node stack with size trie-&gt;max_prefixlen, while it writes (trie-&gt;max_prefixlen + 1) nodes to the stack when it has full paths from the root to leaves. For example, consider a trie with max_prefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ... 0x00/8 inserted. Subsequent calls to trie_get_next_key with _key with .prefixlen = 8 make 9 nodes be written on the node stack with size 8.(CVE-2024-50262)In the Linux kernel, the following vulnerability has been resolved:  ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove()  Syzkaller is able to provoke null-ptr-dereference in ocfs2_xa_remove():  [   57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12 [   57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Partial truncate while removing xattr overlay.upper.  Leaking 1 clusters and removing the entry [   57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004 [...] [   57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [...] [   57.331328] Call Trace: [   57.331477]  &lt;TASK&gt; [...] [   57.333511]  ? do_user_addr_fault+0x3e5/0x740 [   57.333778]  ? exc_page_fault+0x70/0x170 [   57.334016]  ? asm_exc_page_fault+0x2b/0x30 [   57.334263]  ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10 [   57.334596]  ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [   57.334913]  ocfs2_xa_remove_entry+0x23/0xc0 [   57.335164]  ocfs2_xa_set+0x704/0xcf0 [   57.335381]  ? _raw_spin_unlock+0x1a/0x40 [   57.335620]  ? ocfs2_inode_cache_unlock+0x16/0x20 [   57.335915]  ? trace_preempt_on+0x1e/0x70 [   57.336153]  ? start_this_handle+0x16c/0x500 [   57.336410]  ? preempt_count_sub+0x50/0x80 [   57.336656]  ? _raw_read_unlock+0x20/0x40 [   57.336906]  ? start_this_handle+0x16c/0x500 [   57.337162]  ocfs2_xattr_block_set+0xa6/0x1e0 [   57.337424]  __ocfs2_xattr_set_handle+0x1fd/0x5d0 [   57.337706]  ? ocfs2_start_trans+0x13d/0x290 [   57.337971]  ocfs2_xattr_set+0xb13/0xfb0 [   57.338207]  ? dput+0x46/0x1c0 [   57.338393]  ocfs2_xattr_trusted_set+0x28/0x30 [   57.338665]  ? ocfs2_xattr_trusted_set+0x28/0x30 [   57.338948]  __vfs_removexattr+0x92/0xc0 [   57.339182]  __vfs_removexattr_locked+0xd5/0x190 [   57.339456]  ? preempt_count_sub+0x50/0x80 [   57.339705]  vfs_removexattr+0x5f/0x100 [...]  Reproducer uses faultinject facility to fail ocfs2_xa_remove() -&gt; ocfs2_xa_value_truncate() with -ENOMEM.  In this case the comment mentions that we can return 0 if ocfs2_xa_cleanup_value_truncate() is going to wipe the entry anyway. But the following &#39;rc&#39; check is wrong and execution flow do &#39;ocfs2_xa_remove_entry(loc);&#39; twice: * 1st: in ocfs2_xa_cleanup_value_truncate(); * 2nd: returning back to ocfs2_xa_remove() instead of going to &#39;out&#39;.  Fix this by skipping the 2nd removal of the same entry and making syzkaller repro happy.(CVE-2024-50265)In the Linux kernel, the following vulnerability has been resolved:  usb: musb: sunxi: Fix accessing an released usb phy  Commit 6ed05c68cbca (&#34;usb: musb: sunxi: Explicitly release USB PHY on exit&#34;) will cause that usb phy @glue-&gt;xceiv is accessed after released.  1) register platform driver @sunxi_musb_driver // get the usb phy @glue-&gt;xceiv sunxi_musb_probe() -&gt; devm_usb_get_phy().  2) register and unregister platform driver @musb_driver musb_probe() -&gt; sunxi_musb_init() use the phy here //the phy is released here musb_remove() -&gt; sunxi_musb_exit() -&gt; devm_usb_put_phy()  3) register @musb_driver again musb_probe() -&gt; sunxi_musb_init() use the phy here but the phy has been released at 2). ...  Fixed by reverting the commit, namely, removing devm_usb_put_phy() from sunxi_musb_exit().(CVE-2024-50269)In the Linux kernel, the following vulnerability has been resolved:  btrfs: reinitialize delayed ref list after deleting it from the list  At insert_delayed_ref() if we need to update the action of an existing ref to BTRFS_DROP_DELAYED_REF, we delete the ref from its ref head&#39;s ref_add_list using list_del(), which leaves the ref&#39;s add_list member not reinitialized, as list_del() sets the next and prev members of the list to LIST_POISON1 and LIST_POISON2, respectively.  If later we end up calling drop_delayed_ref() against the ref, which can happen during merging or when destroying delayed refs due to a transaction abort, we can trigger a crash since at drop_delayed_ref() we call list_empty() against the ref&#39;s add_list, which returns false since the list was not reinitialized after the list_del() and as a consequence we call list_del() again at drop_delayed_ref(). This results in an invalid list access since the next and prev members are set to poison pointers, resulting in a splat if CONFIG_LIST_HARDENED and CONFIG_DEBUG_LIST are set or invalid poison pointer dereferences otherwise.  So fix this by deleting from the list with list_del_init() instead.(CVE-2024-50273)In the Linux kernel, the following vulnerability has been resolved:  media: av7110: fix a spectre vulnerability  As warned by smatch:  drivers/staging/media/av7110/av7110_ca.c:270 dvb_ca_ioctl() warn: potential spectre issue &#39;av7110-&gt;ci_slot&#39; [w] (local cap)  There is a spectre-related vulnerability at the code. Fix it.(CVE-2024-50289)In the Linux kernel, the following vulnerability has been resolved:  security/keys: fix slab-out-of-bounds in key_task_permission  KASAN reports an out of bounds read: BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36 BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline] BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410 security/keys/permission.c:54 Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362  CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15 Call Trace:  __dump_stack lib/dump_stack.c:82 [inline]  dump_stack+0x107/0x167 lib/dump_stack.c:123  print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400  __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560  kasan_report+0x3a/0x50 mm/kasan/report.c:585  __kuid_val include/linux/uidgid.h:36 [inline]  uid_eq include/linux/uidgid.h:63 [inline]  key_task_permission+0x394/0x410 security/keys/permission.c:54  search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793  This issue was also reported by syzbot.  It can be reproduced by following these steps(more details [1]): 1. Obtain more than 32 inputs that have similar hashes, which ends with the    pattern &#39;0xxxxxxxe6&#39;. 2. Reboot and add the keys obtained in step 1.  The reproducer demonstrates how this issue happened: 1. In the search_nested_keyrings function, when it iterates through the    slots in a node(below tag ascend_to_node), if the slot pointer is meta    and node-&gt;back_pointer != NULL(it means a root), it will proceed to    descend_to_node. However, there is an exception. If node is the root,    and one of the slots points to a shortcut, it will be treated as a    keyring. 2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function.    However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as    ASSOC_ARRAY_PTR_SUBTYPE_MASK. 3. When 32 keys with the similar hashes are added to the tree, the ROOT    has keys with hashes that are not similar (e.g. slot 0) and it splits    NODE A without using a shortcut. When NODE A is filled with keys that    all hashes are xxe6, the keys are similar, NODE A will split with a    shortcut. Finally, it forms the tree as shown below, where slot 6 points    to a shortcut.                        NODE A               +------&gt;+---+       ROOT    |       | 0 | xxe6       +---+   |       +---+  xxxx | 0 | shortcut  :   : xxe6       +---+   |       +---+  xxe6 :   :   |       |   | xxe6       +---+   |       +---+       | 6 |---+       :   : xxe6       +---+           +---+  xxe6 :   :           | f | xxe6       +---+           +---+  xxe6 | f |       +---+  4. As mentioned above, If a slot(slot 6) of the root points to a shortcut,    it may be mistakenly transferred to a key*, leading to a read    out-of-bounds read.  To fix this issue, one should jump to descend_to_node if the ptr is a shortcut, regardless of whether the node is root or not.  [1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/  [jarkko: tweaked the commit message a bit to have an appropriate closes  tag.](CVE-2024-50301)In the Linux kernel, the following vulnerability has been resolved:  io_uring/rw: fix missing NOWAIT check for O_DIRECT start write  When io_uring starts a write, it&#39;ll call kiocb_start_write() to bump the super block rwsem, preventing any freezes from happening while that write is in-flight. The freeze side will grab that rwsem for writing, excluding any new writers from happening and waiting for existing writes to finish. But io_uring unconditionally uses kiocb_start_write(), which will block if someone is currently attempting to freeze the mount point. This causes a deadlock where freeze is waiting for previous writes to complete, but the previous writes cannot complete, as the task that is supposed to complete them is blocked waiting on starting a new write. This results in the following stuck trace showing that dependency with the write blocked starting a new write:  task:fio             state:D stack:0     pid:886   tgid:886   ppid:876 Call trace:  __switch_to+0x1d8/0x348  __schedule+0x8e8/0x2248  schedule+0x110/0x3f0  percpu_rwsem_wait+0x1e8/0x3f8  __percpu_down_read+0xe8/0x500  io_write+0xbb8/0xff8  io_issue_sqe+0x10c/0x1020  io_submit_sqes+0x614/0x2110  __arm64_sys_io_uring_enter+0x524/0x1038  invoke_syscall+0x74/0x268  el0_svc_common.constprop.0+0x160/0x238  do_el0_svc+0x44/0x60  el0_svc+0x44/0xb0  el0t_64_sync_handler+0x118/0x128  el0t_64_sync+0x168/0x170 INFO: task fsfreeze:7364 blocked for more than 15 seconds.       Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963  with the attempting freezer stuck trying to grab the rwsem:  task:fsfreeze        state:D stack:0     pid:7364  tgid:7364  ppid:995 Call trace:  __switch_to+0x1d8/0x348  __schedule+0x8e8/0x2248  schedule+0x110/0x3f0  percpu_down_write+0x2b0/0x680  freeze_super+0x248/0x8a8  do_vfs_ioctl+0x149c/0x1b18  __arm64_sys_ioctl+0xd0/0x1a0  invoke_syscall+0x74/0x268  el0_svc_common.constprop.0+0x160/0x238  do_el0_svc+0x44/0x60  el0_svc+0x44/0xb0  el0t_64_sync_handler+0x118/0x128  el0t_64_sync+0x168/0x170  Fix this by having the io_uring side honor IOCB_NOWAIT, and only attempt a blocking grab of the super block rwsem if it isn&#39;t set. For normal issue where IOCB_NOWAIT would always be set, this returns -EAGAIN which will have io_uring core issue a blocking attempt of the write. That will in turn also get completions run, ensuring forward progress.  Since freezing requires CAP_SYS_ADMIN in the first place, this isn&#39;t something that can be triggered by a regular user.(CVE-2024-53052)In the Linux kernel, the following vulnerability has been resolved:  media: s5p-jpeg: prevent buffer overflows  The current logic allows word to be less than 2. If this happens, there will be buffer overflows, as reported by smatch. Add extra checks to prevent it.  While here, remove an unused word = 0 assignment.(CVE-2024-53061)In the Linux kernel, the following vulnerability has been resolved:  nfs: Fix KMSAN warning in decode_getfattr_attrs()  Fix the following KMSAN warning:  CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G    B Tainted: [B]=BAD_PAGE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) ===================================================== ===================================================== BUG: KMSAN: uninit-value in decode_getfattr_attrs+0x2d6d/0x2f90  decode_getfattr_attrs+0x2d6d/0x2f90  decode_getfattr_generic+0x806/0xb00  nfs4_xdr_dec_getattr+0x1de/0x240  rpcauth_unwrap_resp_decode+0xab/0x100  rpcauth_unwrap_resp+0x95/0xc0  call_decode+0x4ff/0xb50  __rpc_execute+0x57b/0x19d0  rpc_execute+0x368/0x5e0  rpc_run_task+0xcfe/0xee0  nfs4_proc_getattr+0x5b5/0x990  __nfs_revalidate_inode+0x477/0xd00  nfs_access_get_cached+0x1021/0x1cc0  nfs_do_access+0x9f/0xae0  nfs_permission+0x1e4/0x8c0  inode_permission+0x356/0x6c0  link_path_walk+0x958/0x1330  path_lookupat+0xce/0x6b0  filename_lookup+0x23e/0x770  vfs_statx+0xe7/0x970  vfs_fstatat+0x1f2/0x2c0  __se_sys_newfstatat+0x67/0x880  __x64_sys_newfstatat+0xbd/0x120  x64_sys_call+0x1826/0x3cf0  do_syscall_64+0xd0/0x1b0  entry_SYSCALL_64_after_hwframe+0x77/0x7f  The KMSAN warning is triggered in decode_getfattr_attrs(), when calling decode_attr_mdsthreshold(). It appears that fattr-&gt;mdsthreshold is not initialized.  Fix the issue by initializing fattr-&gt;mdsthreshold to NULL in nfs_fattr_init().(CVE-2024-53066)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="bpftool" release="238.0.0.137.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-238.0.0.137.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="238.0.0.137.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-238.0.0.137.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="238.0.0.137.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-238.0.0.137.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="238.0.0.137.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-238.0.0.137.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="238.0.0.137.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-238.0.0.137.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="238.0.0.137.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-238.0.0.137.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="238.0.0.137.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-238.0.0.137.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="238.0.0.137.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-238.0.0.137.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="238.0.0.137.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-238.0.0.137.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="238.0.0.137.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-238.0.0.137.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="238.0.0.137.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-238.0.0.137.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="238.0.0.137.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-238.0.0.137.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="238.0.0.137.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-238.0.0.137.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="238.0.0.137.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-238.0.0.137.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="238.0.0.137.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-238.0.0.137.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="238.0.0.137.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-238.0.0.137.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="238.0.0.137.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-238.0.0.137.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="238.0.0.137.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-238.0.0.137.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="238.0.0.137.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-238.0.0.137.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="238.0.0.137.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-238.0.0.137.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="238.0.0.137.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-238.0.0.137.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="238.0.0.137.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-238.0.0.137.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="238.0.0.137.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-238.0.0.137.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="238.0.0.137.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-238.0.0.137.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="238.0.0.137.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-238.0.0.137.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="238.0.0.137.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-238.0.0.137.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="238.0.0.137.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-238.0.0.137.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="238.0.0.137.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-238.0.0.137.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="238.0.0.137.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-238.0.0.137.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="238.0.0.137.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-238.0.0.137.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2496</id>
          <title>An update for perl-Module-ScanDeps is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-11-29"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-10224" id="CVE-2024-10224" title="CVE-2024-10224" type="cve"></reference>
          </references>
          <description>Qualys discovered that if unsanitized input was used with the library Modules::ScanDeps, before version 1.36 a local attacker could possibly execute arbitrary shell commands by open()ing a &#34;pesky pipe&#34; (such as passing &#34;commands|&#34; as a filename) or by passing arbitrary strings to eval().(CVE-2024-10224)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="perl-Module-ScanDeps" release="2.oe2203sp4" version="1.31">
                         <filename>perl-Module-ScanDeps-1.31-2.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="perl-Module-ScanDeps-help" release="2.oe2203sp4" version="1.31">
                         <filename>perl-Module-ScanDeps-help-1.31-2.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2497</id>
          <title>An update for wget is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-12-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-10524" id="CVE-2024-10524" title="CVE-2024-10524" type="cve"></reference>
          </references>
          <description>Applications that use Wget to access a remote resource using shorthand URLs and pass arbitrary user credentials in the URL are vulnerable. In these cases attackers can enter crafted credentials which will cause Wget to access an arbitrary host.(CVE-2024-10524)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="wget" release="6.oe2203sp4" version="1.21.2">
                         <filename>wget-1.21.2-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="wget-debuginfo" release="6.oe2203sp4" version="1.21.2">
                         <filename>wget-debuginfo-1.21.2-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="wget-debugsource" release="6.oe2203sp4" version="1.21.2">
                         <filename>wget-debugsource-1.21.2-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="wget-help" release="6.oe2203sp4" version="1.21.2">
                         <filename>wget-help-1.21.2-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="wget" release="6.oe2203sp4" version="1.21.2">
                         <filename>wget-1.21.2-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="wget-debuginfo" release="6.oe2203sp4" version="1.21.2">
                         <filename>wget-debuginfo-1.21.2-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="wget-debugsource" release="6.oe2203sp4" version="1.21.2">
                         <filename>wget-debugsource-1.21.2-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="wget-help" release="6.oe2203sp4" version="1.21.2">
                         <filename>wget-help-1.21.2-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2498</id>
          <title>An update for ffmpeg is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2024-12-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35366" id="CVE-2024-35366" title="CVE-2024-35366" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35367" id="CVE-2024-35367" title="CVE-2024-35367" type="cve"></reference>
          </references>
          <description>FFmpeg n6.1.1 is Integer Overflow. The vulnerability exists in the parse_options function of sbgdec.c within the libavformat module. When parsing certain options, the software does not adequately validate the input. This allows for negative duration values to be accepted without proper bounds checking.(CVE-2024-35366)FFmpeg n6.1.1 has an Out-of-bounds Read via libavcodec/ppc/vp8dsp_altivec.c, static const vec_s8 h_subpel_filters_outer(CVE-2024-35367)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="ffmpeg" release="19.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-4.2.4-19.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ffmpeg-debuginfo" release="19.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-debuginfo-4.2.4-19.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ffmpeg-debugsource" release="19.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-debugsource-4.2.4-19.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ffmpeg-devel" release="19.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-devel-4.2.4-19.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ffmpeg-libs" release="19.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-libs-4.2.4-19.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libavdevice" release="19.oe2203sp4" version="4.2.4">
                         <filename>libavdevice-4.2.4-19.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg" release="19.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-4.2.4-19.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg-debuginfo" release="19.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-debuginfo-4.2.4-19.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg-debugsource" release="19.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-debugsource-4.2.4-19.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg-devel" release="19.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-devel-4.2.4-19.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg-libs" release="19.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-libs-4.2.4-19.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libavdevice" release="19.oe2203sp4" version="4.2.4">
                         <filename>libavdevice-4.2.4-19.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2501</id>
          <title>An update for pam is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-12-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-10963" id="CVE-2024-10963" title="CVE-2024-10963" type="cve"></reference>
          </references>
          <description>A vulnerability was found in pam_access due to the improper handling of tokens in access.conf, interpreted as hostnames. This flaw allows attackers to bypass access restrictions by spoofing hostnames, undermining configurations designed to limit access to specific TTYs or services. The flaw poses a risk in environments relying on these configurations for local access control.(CVE-2024-10963)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="pam" release="9.oe2203sp4" version="1.5.2">
                         <filename>pam-1.5.2-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pam-debuginfo" release="9.oe2203sp4" version="1.5.2">
                         <filename>pam-debuginfo-1.5.2-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pam-debugsource" release="9.oe2203sp4" version="1.5.2">
                         <filename>pam-debugsource-1.5.2-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pam-devel" release="9.oe2203sp4" version="1.5.2">
                         <filename>pam-devel-1.5.2-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="pam-help" release="9.oe2203sp4" version="1.5.2">
                         <filename>pam-help-1.5.2-9.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pam" release="9.oe2203sp4" version="1.5.2">
                         <filename>pam-1.5.2-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pam-debuginfo" release="9.oe2203sp4" version="1.5.2">
                         <filename>pam-debuginfo-1.5.2-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pam-debugsource" release="9.oe2203sp4" version="1.5.2">
                         <filename>pam-debugsource-1.5.2-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pam-devel" release="9.oe2203sp4" version="1.5.2">
                         <filename>pam-devel-1.5.2-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2508</id>
          <title>An update for proftpd is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-12-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-48651" id="CVE-2024-48651" title="CVE-2024-48651" type="cve"></reference>
          </references>
          <description>In ProFTPD through 1.3.8b before cec01cc, supplemental group inheritance grants unintended access to GID 0 because of the lack of supplemental groups from mod_sql.(CVE-2024-48651)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="proftpd" release="5.oe2203sp4" version="1.3.8b">
                         <filename>proftpd-1.3.8b-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="proftpd-debuginfo" release="5.oe2203sp4" version="1.3.8b">
                         <filename>proftpd-debuginfo-1.3.8b-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="proftpd-debugsource" release="5.oe2203sp4" version="1.3.8b">
                         <filename>proftpd-debugsource-1.3.8b-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="proftpd-devel" release="5.oe2203sp4" version="1.3.8b">
                         <filename>proftpd-devel-1.3.8b-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="proftpd-ldap" release="5.oe2203sp4" version="1.3.8b">
                         <filename>proftpd-ldap-1.3.8b-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="proftpd-mysql" release="5.oe2203sp4" version="1.3.8b">
                         <filename>proftpd-mysql-1.3.8b-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="proftpd-postgresql" release="5.oe2203sp4" version="1.3.8b">
                         <filename>proftpd-postgresql-1.3.8b-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="proftpd-sqlite" release="5.oe2203sp4" version="1.3.8b">
                         <filename>proftpd-sqlite-1.3.8b-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="proftpd-utils" release="5.oe2203sp4" version="1.3.8b">
                         <filename>proftpd-utils-1.3.8b-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="proftpd" release="5.oe2203sp4" version="1.3.8b">
                         <filename>proftpd-1.3.8b-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="proftpd-debuginfo" release="5.oe2203sp4" version="1.3.8b">
                         <filename>proftpd-debuginfo-1.3.8b-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="proftpd-debugsource" release="5.oe2203sp4" version="1.3.8b">
                         <filename>proftpd-debugsource-1.3.8b-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="proftpd-devel" release="5.oe2203sp4" version="1.3.8b">
                         <filename>proftpd-devel-1.3.8b-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="proftpd-ldap" release="5.oe2203sp4" version="1.3.8b">
                         <filename>proftpd-ldap-1.3.8b-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="proftpd-mysql" release="5.oe2203sp4" version="1.3.8b">
                         <filename>proftpd-mysql-1.3.8b-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="proftpd-postgresql" release="5.oe2203sp4" version="1.3.8b">
                         <filename>proftpd-postgresql-1.3.8b-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="proftpd-sqlite" release="5.oe2203sp4" version="1.3.8b">
                         <filename>proftpd-sqlite-1.3.8b-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="proftpd-utils" release="5.oe2203sp4" version="1.3.8b">
                         <filename>proftpd-utils-1.3.8b-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2509</id>
          <title>An update for python-tornado is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-12-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-52804" id="CVE-2024-52804" title="CVE-2024-52804" type="cve"></reference>
          </references>
          <description>Tornado is a Python web framework and asynchronous networking library. The algorithm used for parsing HTTP cookies in Tornado versions prior to 6.4.2 sometimes has quadratic complexity, leading to excessive CPU consumption when parsing maliciously-crafted cookie headers. This parsing occurs in the event loop thread and may block the processing of other requests. Version 6.4.2 fixes the issue.(CVE-2024-52804)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="python-tornado-debuginfo" release="3.oe2203sp4" version="6.1">
                         <filename>python-tornado-debuginfo-6.1-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python-tornado-debugsource" release="3.oe2203sp4" version="6.1">
                         <filename>python-tornado-debugsource-6.1-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python-tornado-help" release="3.oe2203sp4" version="6.1">
                         <filename>python-tornado-help-6.1-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-tornado" release="3.oe2203sp4" version="6.1">
                         <filename>python3-tornado-6.1-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python-tornado-debuginfo" release="3.oe2203sp4" version="6.1">
                         <filename>python-tornado-debuginfo-6.1-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python-tornado-debugsource" release="3.oe2203sp4" version="6.1">
                         <filename>python-tornado-debugsource-6.1-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python-tornado-help" release="3.oe2203sp4" version="6.1">
                         <filename>python-tornado-help-6.1-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-tornado" release="3.oe2203sp4" version="6.1">
                         <filename>python3-tornado-6.1-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2513</id>
          <title>An update for ansible is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-12-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-8775" id="CVE-2024-8775" title="CVE-2024-8775" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-9902" id="CVE-2024-9902" title="CVE-2024-9902" type="cve"></reference>
          </references>
          <description>Ansible is a radically simple model-driven configuration management, multi-node deployment, and remote task execution system. Ansible works over SSH and does not require any software or daemons to be installed on remote nodes. Extension modules can be written in any language and are transferred to managed machines automatically. %if 0 Provides:            ansible-python3 = - Obsoletes:           ansible-python3 &lt; - BuildRequires:       python3-devel python3-setuptools BuildRequires:       python3-PyYAML python3-paramiko python3-crypto python3-packaging BuildRequires:       python3-pexpect python3-winrm BuildRequires:       git-core %if %with_docs BuildRequires:       python3-sphinx python3-sphinx-theme-alabaster asciidoc %endif BuildRequires:       python3-six python3-nose python3-pytest python3-pytest-xdist BuildRequires:       python3-pytest-mock python3-requests python3-coverage python3-mock BuildRequires:       python3-boto3 python3-botocore python3-passlib python3-jinja2 Requires:            python3-PyYAML python3-paramiko python3-crypto python3-setuptools python3-six Requires:            python3-jinja2 sshpass python3-jmespath %description Ansible is a radically simple model-driven configuration management, multi-node deployment, and remote task execution system. Ansible works over SSH and does not require any software or daemons to be installed on remote nodes. Extension modules can be written in any language and are transferred to managed machines automatically. This package installs versions of ansible that execute on Python3. %endifSecurity Fix(es):A flaw was found in Ansible, where sensitive information stored in Ansible Vault files can be exposed in plaintext during the execution of a playbook. This occurs when using tasks such as include_vars to load vaulted variables without setting the no_log: true parameter, resulting in sensitive data being printed in the playbook output or logs. This can lead to the unintentional disclosure of secrets like passwords or API keys, compromising security and potentially allowing unauthorized access or actions.(CVE-2024-8775)The ansible-core `user` module contains an exploitable flaw that can allow an unprivileged user to silently create or replace the contents of any file on any system path and take ownership of it when a privileged user executes the `user` module against the unprivileged user&#39;s home directory. If the unprivileged user has traversal permissions on the directory containing the exploited target file, they retain full control over the contents of the file as its owner.  Requirements to exploit (if any) - Someone with root privileges must use the `user` module with the`generate_ssh_key` option (disabled by default) and targeting an unprivileged user. - Access to the same unprivileged user on a system managed by the above automation.(CVE-2024-9902)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="ansible" release="5.oe2203sp4" version="2.9.27">
                         <filename>ansible-2.9.27-5.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="ansible-help" release="5.oe2203sp4" version="2.9.27">
                         <filename>ansible-help-2.9.27-5.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2516</id>
          <title>An update for wavpack is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-12-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-2476" id="CVE-2022-2476" title="CVE-2022-2476" type="cve"></reference>
          </references>
          <description>A null pointer dereference bug was found in wavpack-5.4.0 The results from the ASAN log: AddressSanitizer:DEADLYSIGNAL ===================================================================84257==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x561b47a970c6 bp 0x7fff13952fb0 sp 0x7fff1394fca0 T0) ==84257==The signal is caused by a WRITE memory access. ==84257==Hint: address points to the zero page. #0 0x561b47a970c5 in main cli/wvunpack.c:834 #1 0x7efc4f5c0082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082) #2 0x561b47a945ed in _start (/usr/local/bin/wvunpack+0xa5ed) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV cli/wvunpack.c:834 in main ==84257==ABORTING(CVE-2022-2476)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="wavpack" release="3.oe2203sp4" version="5.3.0">
                         <filename>wavpack-5.3.0-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="wavpack-debuginfo" release="3.oe2203sp4" version="5.3.0">
                         <filename>wavpack-debuginfo-5.3.0-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="wavpack-debugsource" release="3.oe2203sp4" version="5.3.0">
                         <filename>wavpack-debugsource-5.3.0-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="wavpack-devel" release="3.oe2203sp4" version="5.3.0">
                         <filename>wavpack-devel-5.3.0-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="wavpack-help" release="3.oe2203sp4" version="5.3.0">
                         <filename>wavpack-help-5.3.0-3.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="wavpack" release="3.oe2203sp4" version="5.3.0">
                         <filename>wavpack-5.3.0-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="wavpack-debuginfo" release="3.oe2203sp4" version="5.3.0">
                         <filename>wavpack-debuginfo-5.3.0-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="wavpack-debugsource" release="3.oe2203sp4" version="5.3.0">
                         <filename>wavpack-debugsource-5.3.0-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="wavpack-devel" release="3.oe2203sp4" version="5.3.0">
                         <filename>wavpack-devel-5.3.0-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2518</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-12-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44950" id="CVE-2024-44950" title="CVE-2024-44950" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46813" id="CVE-2024-46813" title="CVE-2024-46813" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47707" id="CVE-2024-47707" title="CVE-2024-47707" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47718" id="CVE-2024-47718" title="CVE-2024-47718" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49891" id="CVE-2024-49891" title="CVE-2024-49891" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49930" id="CVE-2024-49930" title="CVE-2024-49930" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49938" id="CVE-2024-49938" title="CVE-2024-49938" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49944" id="CVE-2024-49944" title="CVE-2024-49944" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49997" id="CVE-2024-49997" title="CVE-2024-49997" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50024" id="CVE-2024-50024" title="CVE-2024-50024" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50039" id="CVE-2024-50039" title="CVE-2024-50039" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50044" id="CVE-2024-50044" title="CVE-2024-50044" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50135" id="CVE-2024-50135" title="CVE-2024-50135" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50148" id="CVE-2024-50148" title="CVE-2024-50148" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50171" id="CVE-2024-50171" title="CVE-2024-50171" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50196" id="CVE-2024-50196" title="CVE-2024-50196" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50208" id="CVE-2024-50208" title="CVE-2024-50208" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50209" id="CVE-2024-50209" title="CVE-2024-50209" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50234" id="CVE-2024-50234" title="CVE-2024-50234" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50236" id="CVE-2024-50236" title="CVE-2024-50236" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50299" id="CVE-2024-50299" title="CVE-2024-50299" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53059" id="CVE-2024-53059" title="CVE-2024-53059" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53063" id="CVE-2024-53063" title="CVE-2024-53063" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53073" id="CVE-2024-53073" title="CVE-2024-53073" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53090" id="CVE-2024-53090" title="CVE-2024-53090" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53099" id="CVE-2024-53099" title="CVE-2024-53099" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53101" id="CVE-2024-53101" title="CVE-2024-53101" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:serial: sc16is7xx: fix invalid FIFO access with special register setWhen enabling access to the special register set, Receiver time-out andRHR interrupts can happen. In this case, the IRQ handler will try to readfrom the FIFO thru the RHR register at address 0x00, but address 0x00 ismapped to DLL register, resulting in erroneous FIFO reading.Call graph example:    sc16is7xx_startup(): entry    sc16is7xx_ms_proc(): entry    sc16is7xx_set_termios(): entry    sc16is7xx_set_baud(): DLH/DLL = $009C --&gt; access special register set    sc16is7xx_port_irq() entry            --&gt; IIR is 0x0C    sc16is7xx_handle_rx() entry    sc16is7xx_fifo_read(): --&gt; unable to access FIFO (RHR) because it is                               mapped to DLL (LCR=LCR_CONF_MODE_A)    sc16is7xx_set_baud(): exit --&gt; Restore access to general register setFix the problem by claiming the efr_lock mutex when accessing the Specialregister set.(CVE-2024-44950)In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check link_index before accessing dc-&gt;links[][WHY &amp; HOW]dc-&gt;links[] has max size of MAX_LINKS and NULL is return when trying toaccess with out-of-bound index.This fixes 3 OVERRUN and 1 RESOURCE_LEAK issues reported by Coverity.(CVE-2024-46813)In the Linux kernel, the following vulnerability has been resolved:  ipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev()  Blamed commit accidentally removed a check for rt-&gt;rt6i_idev being NULL, as spotted by syzbot:  Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 UID: 0 PID: 10998 Comm: syz-executor Not tainted 6.11.0-rc6-syzkaller-00208-g625403177711 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024  RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline]  RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914 Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df &lt;80&gt; 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0 RBP: ffffc900047375d0 R08: 0000000000000003 R09: fffff520008e6e8c R10: dffffc0000000000 R11: fffff520008e6e8c R12: 1ffff1100fdf8f18 R13: ffff88807efc7998 R14: 0000000000000000 R15: ffff88807efc7930 FS:  0000000000000000(0000) GS:ffff8880b8900000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020002a80 CR3: 0000000022f62000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace:  &lt;TASK&gt;   addrconf_ifdown+0x15d/0x1bd0 net/ipv6/addrconf.c:3856  addrconf_notify+0x3cb/0x1020   notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93   call_netdevice_notifiers_extack net/core/dev.c:2032 [inline]   call_netdevice_notifiers net/core/dev.c:2046 [inline]   unregister_netdevice_many_notify+0xd81/0x1c40 net/core/dev.c:11352   unregister_netdevice_many net/core/dev.c:11414 [inline]   unregister_netdevice_queue+0x303/0x370 net/core/dev.c:11289   unregister_netdevice include/linux/netdevice.h:3129 [inline]   __tun_detach+0x6b9/0x1600 drivers/net/tun.c:685   tun_detach drivers/net/tun.c:701 [inline]   tun_chr_close+0x108/0x1b0 drivers/net/tun.c:3510   __fput+0x24a/0x8a0 fs/file_table.c:422   task_work_run+0x24f/0x310 kernel/task_work.c:228   exit_task_work include/linux/task_work.h:40 [inline]   do_exit+0xa2f/0x27f0 kernel/exit.c:882   do_group_exit+0x207/0x2c0 kernel/exit.c:1031   __do_sys_exit_group kernel/exit.c:1042 [inline]   __se_sys_exit_group kernel/exit.c:1040 [inline]   __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040   x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232   do_syscall_x64 arch/x86/entry/common.c:52 [inline]   do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f1acc77def9 Code: Unable to access opcode bytes at 0x7f1acc77decf. RSP: 002b:00007ffeb26fa738 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1acc77def9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000043 RBP: 00007f1acc7dd508 R08: 00007ffeb26f84d7 R09: 0000000000000003 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 0000000000000003 R14: 00000000ffffffff R15: 00007ffeb26fa8e0  &lt;/TASK&gt; Modules linked in: ---[ end trace 0000000000000000 ]---  RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline]  RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914 Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df &lt;80&gt; 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0 R ---truncated---(CVE-2024-47707)In the Linux kernel, the following vulnerability has been resolved:  wifi: rtw88: always wait for both firmware loading attempts  In &#39;rtw_wait_firmware_completion()&#39;, always wait for both (regular and wowlan) firmware loading attempts. Otherwise if &#39;rtw_usb_intf_init()&#39; has failed in &#39;rtw_usb_probe()&#39;, &#39;rtw_usb_disconnect()&#39; may issue &#39;ieee80211_free_hw()&#39; when one of &#39;rtw_load_firmware_cb()&#39; (usually the wowlan one) is still in progress, causing UAF detected by KASAN.(CVE-2024-47718)In the Linux kernel, the following vulnerability has been resolved:  scsi: lpfc: Validate hdwq pointers before dereferencing in reset/errata paths  When the HBA is undergoing a reset or is handling an errata event, NULL ptr dereference crashes may occur in routines such as lpfc_sli_flush_io_rings(), lpfc_dev_loss_tmo_callbk(), or lpfc_abort_handler().  Add NULL ptr checks before dereferencing hdwq pointers that may have been freed due to operations colliding with a reset or errata event handler.(CVE-2024-49891)In the Linux kernel, the following vulnerability has been resolved:  wifi: ath11k: fix array out-of-bound access in SoC stats  Currently, the ath11k_soc_dp_stats::hal_reo_error array is defined with a maximum size of DP_REO_DST_RING_MAX. However, the ath11k_dp_process_rx() function access ath11k_soc_dp_stats::hal_reo_error using the REO destination SRNG ring ID, which is incorrect. SRNG ring ID differ from normal ring ID, and this usage leads to out-of-bounds array access. To fix this issue, modify ath11k_dp_process_rx() to use the normal ring ID directly instead of the SRNG ring ID to avoid out-of-bounds array access.  Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1(CVE-2024-49930)In the Linux kernel, the following vulnerability has been resolved:  wifi: ath9k_htc: Use __skb_set_length() for resetting urb before resubmit  Syzbot points out that skb_trim() has a sanity check on the existing length of the skb, which can be uninitialised in some error paths. The intent here is clearly just to reset the length to zero before resubmitting, so switch to calling __skb_set_length(skb, 0) directly. In addition, __skb_set_length() already contains a call to skb_reset_tail_pointer(), so remove the redundant call.  The syzbot report came from ath9k_hif_usb_reg_in_cb(), but there&#39;s a similar usage of skb_trim() in ath9k_hif_usb_rx_cb(), change both while we&#39;re at it.(CVE-2024-49938)In the Linux kernel, the following vulnerability has been resolved:  sctp: set sk_state back to CLOSED if autobind fails in sctp_listen_start  In sctp_listen_start() invoked by sctp_inet_listen(), it should set the sk_state back to CLOSED if sctp_autobind() fails due to whatever reason.  Otherwise, next time when calling sctp_inet_listen(), if sctp_sk(sk)-&gt;reuse is already set via setsockopt(SCTP_REUSE_PORT), sctp_sk(sk)-&gt;bind_hash will be dereferenced as sk_state is LISTENING, which causes a crash as bind_hash is NULL.    KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]   RIP: 0010:sctp_inet_listen+0x7f0/0xa20 net/sctp/socket.c:8617   Call Trace:    &lt;TASK&gt;    __sys_listen_socket net/socket.c:1883 [inline]    __sys_listen+0x1b7/0x230 net/socket.c:1894    __do_sys_listen net/socket.c:1902 [inline](CVE-2024-49944)In the Linux kernel, the following vulnerability has been resolved:  net: ethernet: lantiq_etop: fix memory disclosure  When applying padding, the buffer is not zeroed, which results in memory disclosure. The mentioned data is observed on the wire. This patch uses skb_put_padto() to pad Ethernet frames properly. The mentioned function zeroes the expanded buffer.  In case the packet cannot be padded it is silently dropped. Statistics are also not incremented. This driver does not support statistics in the old 32-bit format or the new 64-bit format. These will be added in the future. In its current form, the patch should be easily backported to stable versions.  Ethernet MACs on Amazon-SE and Danube cannot do padding of the packets in hardware, so software padding must be applied.(CVE-2024-49997)In the Linux kernel, the following vulnerability has been resolved:  net: Fix an unsafe loop on the list  The kernel may crash when deleting a genetlink family if there are still listeners for that family:  Oops: Kernel access of bad area, sig: 11 [#1]   ...   NIP [c000000000c080bc] netlink_update_socket_mc+0x3c/0xc0   LR [c000000000c0f764] __netlink_clear_multicast_users+0x74/0xc0   Call Trace: __netlink_clear_multicast_users+0x74/0xc0 genl_unregister_family+0xd4/0x2d0  Change the unsafe loop on the list to a safe one, because inside the loop there is an element removal from this list.(CVE-2024-50024)In the Linux kernel, the following vulnerability has been resolved:  net/sched: accept TCA_STAB only for root qdisc  Most qdiscs maintain their backlog using qdisc_pkt_len(skb) on the assumption it is invariant between the enqueue() and dequeue() handlers.  Unfortunately syzbot can crash a host rather easily using a TBF + SFQ combination, with an STAB on SFQ [1]  We can&#39;t support TCA_STAB on arbitrary level, this would require to maintain per-qdisc storage.  [1] [   88.796496] BUG: kernel NULL pointer dereference, address: 0000000000000000 [   88.798611] #PF: supervisor read access in kernel mode [   88.799014] #PF: error_code(0x0000) - not-present page [   88.799506] PGD 0 P4D 0 [   88.799829] Oops: Oops: 0000 [#1] SMP NOPTI [   88.800569] CPU: 14 UID: 0 PID: 2053 Comm: b371744477 Not tainted 6.12.0-rc1-virtme #1117 [   88.801107] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [   88.801779] RIP: 0010:sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq [ 88.802544] Code: 0f b7 50 12 48 8d 04 d5 00 00 00 00 48 89 d6 48 29 d0 48 8b 91 c0 01 00 00 48 c1 e0 03 48 01 c2 66 83 7a 1a 00 7e c0 48 8b 3a &lt;4c&gt; 8b 07 4c 89 02 49 89 50 08 48 c7 47 08 00 00 00 00 48 c7 07 00 All code ========    0: 0f b7 50 12           movzwl 0x12(%rax),%edx    4: 48 8d 04 d5 00 00 00  lea    0x0(,%rdx,8),%rax    b: 00    c: 48 89 d6              mov    %rdx,%rsi    f: 48 29 d0              sub    %rdx,%rax   12: 48 8b 91 c0 01 00 00  mov    0x1c0(%rcx),%rdx   19: 48 c1 e0 03           shl    $0x3,%rax   1d: 48 01 c2              add    %rax,%rdx   20: 66 83 7a 1a 00        cmpw   $0x0,0x1a(%rdx)   25: 7e c0                 jle    0xffffffffffffffe7   27: 48 8b 3a              mov    (%rdx),%rdi   2a:* 4c 8b 07              mov    (%rdi),%r8  &lt;-- trapping instruction   2d: 4c 89 02              mov    %r8,(%rdx)   30: 49 89 50 08           mov    %rdx,0x8(%r8)   34: 48 c7 47 08 00 00 00  movq   $0x0,0x8(%rdi)   3b: 00   3c: 48                    rex.W   3d: c7                    .byte 0xc7   3e: 07                    (bad)  ...  Code starting with the faulting instruction ===========================================    0: 4c 8b 07              mov    (%rdi),%r8    3: 4c 89 02              mov    %r8,(%rdx)    6: 49 89 50 08           mov    %rdx,0x8(%r8)    a: 48 c7 47 08 00 00 00  movq   $0x0,0x8(%rdi)   11: 00   12: 48                    rex.W   13: c7                    .byte 0xc7   14: 07                    (bad)  ... [   88.803721] RSP: 0018:ffff9a1f892b7d58 EFLAGS: 00000206 [   88.804032] RAX: 0000000000000000 RBX: ffff9a1f8420c800 RCX: ffff9a1f8420c800 [   88.804560] RDX: ffff9a1f81bc1440 RSI: 0000000000000000 RDI: 0000000000000000 [   88.805056] RBP: ffffffffc04bb0e0 R08: 0000000000000001 R09: 00000000ff7f9a1f [   88.805473] R10: 000000000001001b R11: 0000000000009a1f R12: 0000000000000140 [   88.806194] R13: 0000000000000001 R14: ffff9a1f886df400 R15: ffff9a1f886df4ac [   88.806734] FS:  00007f445601a740(0000) GS:ffff9a2e7fd80000(0000) knlGS:0000000000000000 [   88.807225] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [   88.807672] CR2: 0000000000000000 CR3: 000000050cc46000 CR4: 00000000000006f0 [   88.808165] Call Trace: [   88.808459]  &lt;TASK&gt; [   88.808710] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434) [   88.809261] ? page_fault_oops (arch/x86/mm/fault.c:715) [   88.809561] ? exc_page_fault (./arch/x86/include/asm/irqflags.h:26 ./arch/x86/include/asm/irqflags.h:87 ./arch/x86/include/asm/irqflags.h:147 arch/x86/mm/fault.c:1489 arch/x86/mm/fault.c:1539) [   88.809806] ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623) [   88.810074] ? sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq [   88.810411] sfq_reset (net/sched/sch_sfq.c:525) sch_sfq [   88.810671] qdisc_reset (./include/linux/skbuff.h:2135 ./include/linux/skbuff.h:2441 ./include/linux/skbuff.h:3304 ./include/linux/skbuff.h:3310 net/sched/sch_g ---truncated---(CVE-2024-50039)In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change  rfcomm_sk_state_change attempts to use sock_lock so it must never be called with it locked but rfcomm_sock_ioctl always attempt to lock it causing the following trace:  ====================================================== WARNING: possible circular locking dependency detected 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Not tainted ------------------------------------------------------ syz-executor386/5093 is trying to acquire lock: ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1671 [inline] ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: rfcomm_sk_state_change+0x5b/0x310 net/bluetooth/rfcomm/sock.c:73  but task is already holding lock: ffff88807badfd28 (&amp;d-&gt;lock){+.+.}-{3:3}, at: __rfcomm_dlc_close+0x226/0x6a0 net/bluetooth/rfcomm/core.c:491(CVE-2024-50044)In the Linux kernel, the following vulnerability has been resolved:  nvme-pci: fix race condition between reset and nvme_dev_disable()  nvme_dev_disable() modifies the dev-&gt;online_queues field, therefore nvme_pci_update_nr_queues() should avoid racing against it, otherwise we could end up passing invalid values to blk_mq_update_nr_hw_queues().   WARNING: CPU: 39 PID: 61303 at drivers/pci/msi/api.c:347           pci_irq_get_affinity+0x187/0x210  Workqueue: nvme-reset-wq nvme_reset_work [nvme]  RIP: 0010:pci_irq_get_affinity+0x187/0x210  Call Trace:   &lt;TASK&gt;   ? blk_mq_pci_map_queues+0x87/0x3c0   ? pci_irq_get_affinity+0x187/0x210   blk_mq_pci_map_queues+0x87/0x3c0   nvme_pci_map_queues+0x189/0x460 [nvme]   blk_mq_update_nr_hw_queues+0x2a/0x40   nvme_reset_work+0x1be/0x2a0 [nvme]  Fix the bug by locking the shutdown_lock mutex before using dev-&gt;online_queues. Give up if nvme_dev_disable() is running or if it has been executed already.(CVE-2024-50135)In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: bnep: fix wild-memory-access in proto_unregister  There&#39;s issue as follows:   KASAN: maybe wild-memory-access in range [0xdead...108-0xdead...10f]   CPU: 3 UID: 0 PID: 2805 Comm: rmmod Tainted: G        W   RIP: 0010:proto_unregister+0xee/0x400   Call Trace:    &lt;TASK&gt;    __do_sys_delete_module+0x318/0x580    do_syscall_64+0xc1/0x1d0    entry_SYSCALL_64_after_hwframe+0x77/0x7f  As bnep_init() ignore bnep_sock_init()&#39;s return value, and bnep_sock_init() will cleanup all resource. Then when remove bnep module will call bnep_sock_cleanup() to cleanup sock&#39;s resource. To solve above issue just return bnep_sock_init()&#39;s return value in bnep_exit().(CVE-2024-50148)In the Linux kernel, the following vulnerability has been resolved:  net: systemport: fix potential memory leak in bcm_sysport_xmit()  The bcm_sysport_xmit() returns NETDEV_TX_OK without freeing skb in case of dma_map_single() fails, add dev_kfree_skb() to fix it.(CVE-2024-50171)In the Linux kernel, the following vulnerability has been resolved:  pinctrl: ocelot: fix system hang on level based interrupts  The current implementation only calls chained_irq_enter() and chained_irq_exit() if it detects pending interrupts.  ``` for (i = 0; i &lt; info-&gt;stride; i++) {  uregmap_read(info-&gt;map, id_reg + 4 * i, &amp;reg);  if (!reg)   continue;   chained_irq_enter(parent_chip, desc); ```  However, in case of GPIO pin configured in level mode and the parent controller configured in edge mode, GPIO interrupt might be lowered by the hardware. In the result, if the interrupt is short enough, the parent interrupt is still pending while the GPIO interrupt is cleared; chained_irq_enter() never gets called and the system hangs trying to service the parent interrupt.  Moving chained_irq_enter() and chained_irq_exit() outside the for loop ensures that they are called even when GPIO interrupt is lowered by the hardware.  The similar code with chained_irq_enter() / chained_irq_exit() functions wrapping interrupt checking loop may be found in many other drivers: ``` grep -r -A 10 chained_irq_enter drivers/pinctrl ```(CVE-2024-50196)In the Linux kernel, the following vulnerability has been resolved:  RDMA/bnxt_re: Fix a bug while setting up Level-2 PBL pages  Avoid memory corruption while setting up Level-2 PBL pages for the non MR resources when num_pages &gt; 256K.  There will be a single PDE page address (contiguous pages in the case of &gt; PAGE_SIZE), but, current logic assumes multiple pages, leading to invalid memory access after 256K PBL entries in the PDE.(CVE-2024-50208)In the Linux kernel, the following vulnerability has been resolved:  RDMA/bnxt_re: Add a check for memory allocation  __alloc_pbl() can return error when memory allocation fails. Driver is not checking the status on one of the instances.(CVE-2024-50209)In the Linux kernel, the following vulnerability has been resolved:  wifi: iwlegacy: Clear stale interrupts before resuming device  iwl4965 fails upon resume from hibernation on my laptop. The reason seems to be a stale interrupt which isn&#39;t being cleared out before interrupts are enabled. We end up with a race beween the resume trying to bring things back up, and the restart work (queued form the interrupt handler) trying to bring things down. Eventually the whole thing blows up.  Fix the problem by clearing out any stale interrupts before interrupts get enabled during resume.  Here&#39;s a debug log of the indicent: [   12.042589] ieee80211 phy0: il_isr ISR inta 0x00000080, enabled 0xaa00008b, fh 0x00000000 [   12.042625] ieee80211 phy0: il4965_irq_tasklet inta 0x00000080, enabled 0x00000000, fh 0x00000000 [   12.042651] iwl4965 0000:10:00.0: RF_KILL bit toggled to enable radio. [   12.042653] iwl4965 0000:10:00.0: On demand firmware reload [   12.042690] ieee80211 phy0: il4965_irq_tasklet End inta 0x00000000, enabled 0xaa00008b, fh 0x00000000, flags 0x00000282 [   12.052207] ieee80211 phy0: il4965_mac_start enter [   12.052212] ieee80211 phy0: il_prep_station Add STA to driver ID 31: ff:ff:ff:ff:ff:ff [   12.052244] ieee80211 phy0: il4965_set_hw_ready hardware  ready [   12.052324] ieee80211 phy0: il_apm_init Init card&#39;s basic functions [   12.052348] ieee80211 phy0: il_apm_init L1 Enabled; Disabling L0S [   12.055727] ieee80211 phy0: il4965_load_bsm Begin load bsm [   12.056140] ieee80211 phy0: il4965_verify_bsm Begin verify bsm [   12.058642] ieee80211 phy0: il4965_verify_bsm BSM bootstrap uCode image OK [   12.058721] ieee80211 phy0: il4965_load_bsm BSM write complete, poll 1 iterations [   12.058734] ieee80211 phy0: __il4965_up iwl4965 is coming up [   12.058737] ieee80211 phy0: il4965_mac_start Start UP work done. [   12.058757] ieee80211 phy0: __il4965_down iwl4965 is going down [   12.058761] ieee80211 phy0: il_scan_cancel_timeout Scan cancel timeout [   12.058762] ieee80211 phy0: il_do_scan_abort Not performing scan to abort [   12.058765] ieee80211 phy0: il_clear_ucode_stations Clearing ucode stations in driver [   12.058767] ieee80211 phy0: il_clear_ucode_stations No active stations found to be cleared [   12.058819] ieee80211 phy0: _il_apm_stop Stop card, put in low power state [   12.058827] ieee80211 phy0: _il_apm_stop_master stop master [   12.058864] ieee80211 phy0: il4965_clear_free_frames 0 frames on pre-allocated heap on clear. [   12.058869] ieee80211 phy0: Hardware restart was requested [   16.132299] iwl4965 0000:10:00.0: START_ALIVE timeout after 4000ms. [   16.132303] ------------[ cut here ]------------ [   16.132304] Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue. [   16.132338] WARNING: CPU: 0 PID: 181 at net/mac80211/util.c:1826 ieee80211_reconfig+0x8f/0x14b0 [mac80211] [   16.132390] Modules linked in: ctr ccm sch_fq_codel xt_tcpudp xt_multiport xt_state iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv4 ip_tables x_tables binfmt_misc joydev mousedev btusb btrtl btintel btbcm bluetooth ecdh_generic ecc iTCO_wdt i2c_dev iwl4965 iwlegacy coretemp snd_hda_codec_analog pcspkr psmouse mac80211 snd_hda_codec_generic libarc4 sdhci_pci cqhci sha256_generic sdhci libsha256 firewire_ohci snd_hda_intel snd_intel_dspcfg mmc_core snd_hda_codec snd_hwdep firewire_core led_class iosf_mbi snd_hda_core uhci_hcd lpc_ich crc_itu_t cfg80211 ehci_pci ehci_hcd snd_pcm usbcore mfd_core rfkill snd_timer snd usb_common soundcore video parport_pc parport intel_agp wmi intel_gtt backlight e1000e agpgart evdev [   16.132456] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Not tainted 6.11.0-cl+ #143 [   16.132460] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. F.19 07/06/2010 [   16.132463] Workqueue: async async_run_entry_fn [   16.132469] RIP: 0010:ieee80211_reconfig+0x8f/0x14b0 [mac80211] [   16.132501] Code: da 02 00 0 ---truncated---(CVE-2024-50234)In the Linux kernel, the following vulnerability has been resolved:  wifi: ath10k: Fix memory leak in management tx  In the current logic, memory is allocated for storing the MSDU context during management packet TX but this memory is not being freed during management TX completion. Similar leaks are seen in the management TX cleanup logic.  Kmemleak reports this problem as below,  unreferenced object 0xffffff80b64ed250 (size 16):   comm &#34;kworker/u16:7&#34;, pid 148, jiffies 4294687130 (age 714.199s)   hex dump (first 16 bytes):     00 2b d8 d8 80 ff ff ff c4 74 e9 fd 07 00 00 00  .+.......t......   backtrace:     [&lt;ffffffe6e7b245dc&gt;] __kmem_cache_alloc_node+0x1e4/0x2d8     [&lt;ffffffe6e7adde88&gt;] kmalloc_trace+0x48/0x110     [&lt;ffffffe6bbd765fc&gt;] ath10k_wmi_tlv_op_gen_mgmt_tx_send+0xd4/0x1d8 [ath10k_core]     [&lt;ffffffe6bbd3eed4&gt;] ath10k_mgmt_over_wmi_tx_work+0x134/0x298 [ath10k_core]     [&lt;ffffffe6e78d5974&gt;] process_scheduled_works+0x1ac/0x400     [&lt;ffffffe6e78d60b8&gt;] worker_thread+0x208/0x328     [&lt;ffffffe6e78dc890&gt;] kthread+0x100/0x1c0     [&lt;ffffffe6e78166c0&gt;] ret_from_fork+0x10/0x20  Free the memory during completion and cleanup to fix the leak.  Protect the mgmt_pending_tx idr_remove() operation in ath10k_wmi_tlv_op_cleanup_mgmt_tx_send() using ar-&gt;data_lock similar to other instances.  Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1(CVE-2024-50236)In the Linux kernel, the following vulnerability has been resolved:  sctp: properly validate chunk size in sctp_sf_ootb()  A size validation fix similar to that in Commit 50619dbf8db7 (&#34;sctp: add size validation when walking chunks&#34;) is also required in sctp_sf_ootb() to address a crash reported by syzbot:    BUG: KMSAN: uninit-value in sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712   sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712   sctp_do_sm+0x181/0x93d0 net/sctp/sm_sideeffect.c:1166   sctp_endpoint_bh_rcv+0xc38/0xf90 net/sctp/endpointola.c:407   sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88   sctp_rcv+0x3831/0x3b20 net/sctp/input.c:243   sctp4_rcv+0x42/0x50 net/sctp/protocol.c:1159   ip_protocol_deliver_rcu+0xb51/0x13d0 net/ipv4/ip_input.c:205   ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233(CVE-2024-50299)In the Linux kernel, the following vulnerability has been resolved:  wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd()  1. The size of the response packet is not validated. 2. The response buffer is not freed.  Resolve these issues by switching to iwl_mvm_send_cmd_status(), which handles both size validation and frees the buffer.(CVE-2024-53059)In the Linux kernel, the following vulnerability has been resolved:  media: dvbdev: prevent the risk of out of memory access  The dvbdev contains a static variable used to store dvb minors.  The behavior of it depends if CONFIG_DVB_DYNAMIC_MINORS is set or not. When not set, dvb_register_device() won&#39;t check for boundaries, as it will rely that a previous call to dvb_register_adapter() would already be enforcing it.  On a similar way, dvb_device_open() uses the assumption that the register functions already did the needed checks.  This can be fragile if some device ends using different calls. This also generate warnings on static check analysers like Coverity.  So, add explicit guards to prevent potential risk of OOM issues.(CVE-2024-53063)In the Linux kernel, the following vulnerability has been resolved:  NFSD: Never decrement pending_async_copies on error  The error flow in nfsd4_copy() calls cleanup_async_copy(), which already decrements nn-&gt;pending_async_copies.(CVE-2024-53073)In the Linux kernel, the following vulnerability has been resolved:  afs: Fix lock recursion  afs_wake_up_async_call() can incur lock recursion.  The problem is that it is called from AF_RXRPC whilst holding the -&gt;notify_lock, but it tries to take a ref on the afs_call struct in order to pass it to a work queue - but if the afs_call is already queued, we then have an extraneous ref that must be put... calling afs_put_call() may call back down into AF_RXRPC through rxrpc_kernel_shutdown_call(), however, which might try taking the -&gt;notify_lock again.  This case isn&#39;t very common, however, so defer it to a workqueue.  The oops looks something like:    BUG: spinlock recursion on CPU#0, krxrpcio/7001/1646    lock: 0xffff888141399b30, .magic: dead4ead, .owner: krxrpcio/7001/1646, .owner_cpu: 0   CPU: 0 UID: 0 PID: 1646 Comm: krxrpcio/7001 Not tainted 6.12.0-rc2-build3+ #4351   Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014   Call Trace:    &lt;TASK&gt;    dump_stack_lvl+0x47/0x70    do_raw_spin_lock+0x3c/0x90    rxrpc_kernel_shutdown_call+0x83/0xb0    afs_put_call+0xd7/0x180    rxrpc_notify_socket+0xa0/0x190    rxrpc_input_split_jumbo+0x198/0x1d0    rxrpc_input_data+0x14b/0x1e0    ? rxrpc_input_call_packet+0xc2/0x1f0    rxrpc_input_call_event+0xad/0x6b0    rxrpc_input_packet_on_conn+0x1e1/0x210    rxrpc_input_packet+0x3f2/0x4d0    rxrpc_io_thread+0x243/0x410    ? __pfx_rxrpc_io_thread+0x10/0x10    kthread+0xcf/0xe0    ? __pfx_kthread+0x10/0x10    ret_from_fork+0x24/0x40    ? __pfx_kthread+0x10/0x10    ret_from_fork_asm+0x1a/0x30    &lt;/TASK&gt;(CVE-2024-53090)In the Linux kernel, the following vulnerability has been resolved:  bpf: Check validity of link-&gt;type in bpf_link_show_fdinfo()  If a newly-added link type doesn&#39;t invoke BPF_LINK_TYPE(), accessing bpf_link_type_strs[link-&gt;type] may result in an out-of-bounds access.  To spot such missed invocations early in the future, checking the validity of link-&gt;type in bpf_link_show_fdinfo() and emitting a warning when such invocations are missed.(CVE-2024-53099)In the Linux kernel, the following vulnerability has been resolved:  fs: Fix uninitialized value issue in from_kuid and from_kgid  ocfs2_setattr() uses attr-&gt;ia_mode, attr-&gt;ia_uid and attr-&gt;ia_gid in a trace point even though ATTR_MODE, ATTR_UID and ATTR_GID aren&#39;t set.  Initialize all fields of newattrs to avoid uninitialized variables, by checking if ATTR_MODE, ATTR_UID, ATTR_GID are initialized, otherwise 0.(CVE-2024-53101)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="bpftool" release="239.0.0.138.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-239.0.0.138.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="239.0.0.138.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-239.0.0.138.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="239.0.0.138.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-239.0.0.138.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="239.0.0.138.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-239.0.0.138.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="239.0.0.138.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-239.0.0.138.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="239.0.0.138.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-239.0.0.138.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="239.0.0.138.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-239.0.0.138.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="239.0.0.138.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-239.0.0.138.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="239.0.0.138.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-239.0.0.138.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="239.0.0.138.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-239.0.0.138.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="239.0.0.138.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-239.0.0.138.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="239.0.0.138.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-239.0.0.138.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="239.0.0.138.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-239.0.0.138.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="239.0.0.138.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-239.0.0.138.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="239.0.0.138.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-239.0.0.138.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="239.0.0.138.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-239.0.0.138.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="239.0.0.138.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-239.0.0.138.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="239.0.0.138.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-239.0.0.138.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="239.0.0.138.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-239.0.0.138.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="239.0.0.138.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-239.0.0.138.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="239.0.0.138.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-239.0.0.138.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="239.0.0.138.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-239.0.0.138.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="239.0.0.138.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-239.0.0.138.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="239.0.0.138.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-239.0.0.138.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="239.0.0.138.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-239.0.0.138.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="239.0.0.138.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-239.0.0.138.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="239.0.0.138.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-239.0.0.138.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="239.0.0.138.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-239.0.0.138.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="239.0.0.138.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-239.0.0.138.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="239.0.0.138.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-239.0.0.138.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2524</id>
          <title>An update for microcode_ctl is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-12-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21820" id="CVE-2024-21820" title="CVE-2024-21820" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21853" id="CVE-2024-21853" title="CVE-2024-21853" type="cve"></reference>
          </references>
          <description>(CVE-2024-21820)(CVE-2024-21853)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="x86_64" name="microcode_ctl" release="1.oe2203sp4" version="20241112">
                         <filename>microcode_ctl-20241112-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2529</id>
          <title>An update for docker is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-12-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36621" id="CVE-2024-36621" title="CVE-2024-36621" type="cve"></reference>
          </references>
          <description>moby v25.0.5 is affected by a Race Condition in builder/builder-next/adapters/snapshot/layer.go. The vulnerability could be used to trigger concurrent builds that call the EnsureLayer function resulting in resource leaks/exhaustion.(CVE-2024-36621)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="2" arch="aarch64" name="docker-engine" release="344.oe2203sp4" version="18.09.0">
                         <filename>docker-engine-18.09.0-344.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="docker-engine-debuginfo" release="344.oe2203sp4" version="18.09.0">
                         <filename>docker-engine-debuginfo-18.09.0-344.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="docker-engine-debugsource" release="344.oe2203sp4" version="18.09.0">
                         <filename>docker-engine-debugsource-18.09.0-344.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="docker-engine" release="344.oe2203sp4" version="18.09.0">
                         <filename>docker-engine-18.09.0-344.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="docker-engine-debuginfo" release="344.oe2203sp4" version="18.09.0">
                         <filename>docker-engine-debuginfo-18.09.0-344.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="docker-engine-debugsource" release="344.oe2203sp4" version="18.09.0">
                         <filename>docker-engine-debugsource-18.09.0-344.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2530</id>
          <title>An update for tuned is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-12-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-52336" id="CVE-2024-52336" title="CVE-2024-52336" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-52337" id="CVE-2024-52337" title="CVE-2024-52337" type="cve"></reference>
          </references>
          <description>A script injection vulnerability was identified in the Tuned package. The `instance_create()` D-Bus function can be called by locally logged-in users without authentication. This flaw allows a local non-privileged user to execute a D-Bus call with `script_pre` or `script_post` options that permit arbitrary scripts with their absolute paths to be passed. These user or attacker-controlled executable scripts or programs could then be executed by Tuned with root privileges that could allow attackers to local privilege escalation.(CVE-2024-52336)A log spoofing flaw was found in the Tuned package due to improper sanitization of some API arguments. This flaw allows an attacker to pass a controlled sequence of characters; newlines can be inserted into the log. Instead of the &#39;evil&#39; the attacker could mimic a valid TuneD log line and trick the administrator. The quotes &#39;&#39; are usually used in TuneD logs citing raw user input, so there will always be the &#39; character ending the spoofed input, and the administrator can easily overlook this. This logged string is later used in logging and in the output of utilities, for example, `tuned-adm get_instances` or other third-party programs that use Tuned&#39;s D-Bus interface for such operations.(CVE-2024-52337)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="tuned" release="1.oe2203sp4" version="2.24.1">
                         <filename>tuned-2.24.1-1.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="tuned-help" release="1.oe2203sp4" version="2.24.1">
                         <filename>tuned-help-2.24.1-1.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="tuned-profiles-devel" release="1.oe2203sp4" version="2.24.1">
                         <filename>tuned-profiles-devel-2.24.1-1.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2532</id>
          <title>An update for kubernetes is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-12-13"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-10220" id="CVE-2024-10220" title="CVE-2024-10220" type="cve"></reference>
          </references>
          <description>A vulnerability, which was classified as problematic, was found in Kubernetes up to 1.28.11/1.29.6/1.30.2 (Virtualization Software). Affected is an unknown code block of the component gitRepo Volume Handler. Upgrading to version 1.28.12, 1.29.7, 1.30.3 or 1.31.0 eliminates this vulnerability. Applying a patch is able to eliminate this problem. The bugfix is ready for download at github.com. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2024-10220)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kubernetes" release="26.oe2203sp4" version="1.20.2">
                         <filename>kubernetes-1.20.2-26.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kubernetes-client" release="26.oe2203sp4" version="1.20.2">
                         <filename>kubernetes-client-1.20.2-26.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kubernetes-help" release="26.oe2203sp4" version="1.20.2">
                         <filename>kubernetes-help-1.20.2-26.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kubernetes-kubeadm" release="26.oe2203sp4" version="1.20.2">
                         <filename>kubernetes-kubeadm-1.20.2-26.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kubernetes-kubelet" release="26.oe2203sp4" version="1.20.2">
                         <filename>kubernetes-kubelet-1.20.2-26.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kubernetes-master" release="26.oe2203sp4" version="1.20.2">
                         <filename>kubernetes-master-1.20.2-26.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kubernetes-node" release="26.oe2203sp4" version="1.20.2">
                         <filename>kubernetes-node-1.20.2-26.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kubernetes" release="26.oe2203sp4" version="1.20.2">
                         <filename>kubernetes-1.20.2-26.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kubernetes-client" release="26.oe2203sp4" version="1.20.2">
                         <filename>kubernetes-client-1.20.2-26.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kubernetes-help" release="26.oe2203sp4" version="1.20.2">
                         <filename>kubernetes-help-1.20.2-26.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kubernetes-kubeadm" release="26.oe2203sp4" version="1.20.2">
                         <filename>kubernetes-kubeadm-1.20.2-26.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kubernetes-kubelet" release="26.oe2203sp4" version="1.20.2">
                         <filename>kubernetes-kubelet-1.20.2-26.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kubernetes-master" release="26.oe2203sp4" version="1.20.2">
                         <filename>kubernetes-master-1.20.2-26.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kubernetes-node" release="26.oe2203sp4" version="1.20.2">
                         <filename>kubernetes-node-1.20.2-26.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2533</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-12-13"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47713" id="CVE-2024-47713" title="CVE-2024-47713" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49861" id="CVE-2024-49861" title="CVE-2024-49861" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49863" id="CVE-2024-49863" title="CVE-2024-49863" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49906" id="CVE-2024-49906" title="CVE-2024-49906" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49923" id="CVE-2024-49923" title="CVE-2024-49923" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49977" id="CVE-2024-49977" title="CVE-2024-49977" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49991" id="CVE-2024-49991" title="CVE-2024-49991" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50103" id="CVE-2024-50103" title="CVE-2024-50103" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50116" id="CVE-2024-50116" title="CVE-2024-50116" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50127" id="CVE-2024-50127" title="CVE-2024-50127" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50134" id="CVE-2024-50134" title="CVE-2024-50134" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50187" id="CVE-2024-50187" title="CVE-2024-50187" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50201" id="CVE-2024-50201" title="CVE-2024-50201" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50267" id="CVE-2024-50267" title="CVE-2024-50267" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50272" id="CVE-2024-50272" title="CVE-2024-50272" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50278" id="CVE-2024-50278" title="CVE-2024-50278" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50290" id="CVE-2024-50290" title="CVE-2024-50290" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50292" id="CVE-2024-50292" title="CVE-2024-50292" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50302" id="CVE-2024-50302" title="CVE-2024-50302" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53104" id="CVE-2024-53104" title="CVE-2024-53104" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53110" id="CVE-2024-53110" title="CVE-2024-53110" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53112" id="CVE-2024-53112" title="CVE-2024-53112" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53125" id="CVE-2024-53125" title="CVE-2024-53125" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53130" id="CVE-2024-53130" title="CVE-2024-53130" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:  wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop()  Since &#39;__dev_queue_xmit()&#39; should be called with interrupts enabled, the following backtrace:  ieee80211_do_stop()  ...  spin_lock_irqsave(&amp;local-&gt;queue_stop_reason_lock, flags)  ...  ieee80211_free_txskb()   ieee80211_report_used_skb()    ieee80211_report_ack_skb()     cfg80211_mgmt_tx_status_ext()      nl80211_frame_tx_status()       genlmsg_multicast_netns()        genlmsg_multicast_netns_filtered()         nlmsg_multicast_filtered()   netlink_broadcast_filtered()    do_one_broadcast()     netlink_broadcast_deliver()      __netlink_sendskb()       netlink_deliver_tap()        __netlink_deliver_tap_skb()         dev_queue_xmit()          __dev_queue_xmit() ; with IRQS disabled  ...  spin_unlock_irqrestore(&amp;local-&gt;queue_stop_reason_lock, flags)  issues the warning (as reported by syzbot reproducer):  WARNING: CPU: 2 PID: 5128 at kernel/softirq.c:362 __local_bh_enable_ip+0xc3/0x120  Fix this by implementing a two-phase skb reclamation in &#39;ieee80211_do_stop()&#39;, where actual work is performed outside of a section with interrupts disabled.(CVE-2024-47713)In the Linux kernel, the following vulnerability has been resolved:  bpf: Fix helper writes to read-only maps  Lonial found an issue that despite user- and BPF-side frozen BPF map (like in case of .rodata), it was still possible to write into it from a BPF program side through specific helpers having ARG_PTR_TO_{LONG,INT} as arguments.  In check_func_arg() when the argument is as mentioned, the meta-&gt;raw_mode is never set. Later, check_helper_mem_access(), under the case of PTR_TO_MAP_VALUE as register base type, it assumes BPF_READ for the subsequent call to check_map_access_type() and given the BPF map is read-only it succeeds.  The helpers really need to be annotated as ARG_PTR_TO_{LONG,INT} | MEM_UNINIT when results are written into them as opposed to read out of them. The latter indicates that it&#39;s okay to pass a pointer to uninitialized memory as the memory is written to anyway.  However, ARG_PTR_TO_{LONG,INT} is a special case of ARG_PTR_TO_FIXED_SIZE_MEM just with additional alignment requirement. So it is better to just get rid of the ARG_PTR_TO_{LONG,INT} special cases altogether and reuse the fixed size memory types. For this, add MEM_ALIGNED to additionally ensure alignment given these helpers write directly into the args via *&lt;ptr&gt; = val. The .arg*_size has been initialized reflecting the actual sizeof(*&lt;ptr&gt;).  MEM_ALIGNED can only be used in combination with MEM_FIXED_SIZE annotated argument types, since in !MEM_FIXED_SIZE cases the verifier does not know the buffer size a priori and therefore cannot blindly write *&lt;ptr&gt; = val.(CVE-2024-49861)In the Linux kernel, the following vulnerability has been resolved:  vhost/scsi: null-ptr-dereference in vhost_scsi_get_req()  Since commit 3f8ca2e115e5 (&#34;vhost/scsi: Extract common handling code from control queue handler&#34;) a null pointer dereference bug can be triggered when guest sends an SCSI AN request.  In vhost_scsi_ctl_handle_vq(), `vc.target` is assigned with `&amp;v_req.tmf.lun[1]` within a switch-case block and is then passed to vhost_scsi_get_req() which extracts `vc-&gt;req` and `tpg`. However, for a `VIRTIO_SCSI_T_AN_*` request, tpg is not required, so `vc.target` is set to NULL in this branch. Later, in vhost_scsi_get_req(), `vc-&gt;target` is dereferenced without being checked, leading to a null pointer dereference bug. This bug can be triggered from guest.  When this bug occurs, the vhost_worker process is killed while holding `vq-&gt;mutex` and the corresponding tpg will remain occupied indefinitely.  Below is the KASAN report: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 PID: 840 Comm: poc Not tainted 6.10.0+ #1 Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:vhost_scsi_get_req+0x165/0x3a0 Code: 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 2b 02 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 65 30 4c 89 e2 48 c1 ea 03 &lt;0f&gt; b6 04 02 4c 89 e2 83 e2 07 38 d0 7f 08 84 c0 0f 85 be 01 00 00 RSP: 0018:ffff888017affb50 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffff88801b000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888017affcb8 RBP: ffff888017affb80 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff888017affc88 R14: ffff888017affd1c R15: ffff888017993000 FS:  000055556e076500(0000) GS:ffff88806b100000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200027c0 CR3: 0000000010ed0004 CR4: 0000000000370ef0 Call Trace:  &lt;TASK&gt;  ? show_regs+0x86/0xa0  ? die_addr+0x4b/0xd0  ? exc_general_protection+0x163/0x260  ? asm_exc_general_protection+0x27/0x30  ? vhost_scsi_get_req+0x165/0x3a0  vhost_scsi_ctl_handle_vq+0x2a4/0xca0  ? __pfx_vhost_scsi_ctl_handle_vq+0x10/0x10  ? __switch_to+0x721/0xeb0  ? __schedule+0xda5/0x5710  ? __kasan_check_write+0x14/0x30  ? _raw_spin_lock+0x82/0xf0  vhost_scsi_ctl_handle_kick+0x52/0x90  vhost_run_work_list+0x134/0x1b0  vhost_task_fn+0x121/0x350 ...  &lt;/TASK&gt; ---[ end trace 0000000000000000 ]---  Let&#39;s add a check in vhost_scsi_get_req.  [whitespace fixes](CVE-2024-49863)In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Check null pointer before try to access it  [why &amp; how] Change the order of the pipe_ctx-&gt;plane_state check to ensure that plane_state is not null before accessing it.(CVE-2024-49906)In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Pass non-null to dcn20_validate_apply_pipe_split_flags  [WHAT &amp; HOW] &#34;dcn20_validate_apply_pipe_split_flags&#34; dereferences merge, and thus it cannot be a null pointer. Let&#39;s pass a valid pointer to avoid null dereference.  This fixes 2 FORWARD_NULL issues reported by Coverity.(CVE-2024-49923)In the Linux kernel, the following vulnerability has been resolved:  net: stmmac: Fix zero-division error when disabling tc cbs  The commit b8c43360f6e4 (&#34;net: stmmac: No need to calculate speed divider when offload is disabled&#34;) allows the &#34;port_transmit_rate_kbps&#34; to be set to a value of 0, which is then passed to the &#34;div_s64&#34; function when tc-cbs is disabled. This leads to a zero-division error.  When tc-cbs is disabled, the idleslope, sendslope, and credit values the credit values are not required to be configured. Therefore, adding a return statement after setting the txQ mode to DCB when tc-cbs is disabled would prevent a zero-division error.(CVE-2024-49977)In the Linux kernel, the following vulnerability has been resolved:  drm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer  Pass pointer reference to amdgpu_bo_unref to clear the correct pointer, otherwise amdgpu_bo_unref clear the local variable, the original pointer not set to NULL, this could cause use-after-free bug.(CVE-2024-49991)In the Linux kernel, the following vulnerability has been resolved:  ASoC: qcom: Fix NULL Dereference in asoc_qcom_lpass_cpu_platform_probe()  A devm_kzalloc() in asoc_qcom_lpass_cpu_platform_probe() could possibly return NULL pointer. NULL Pointer Dereference may be triggerred without addtional check. Add a NULL check for the returned pointer.(CVE-2024-50103)In the Linux kernel, the following vulnerability has been resolved:  nilfs2: fix kernel bug due to missing clearing of buffer delay flag  Syzbot reported that after nilfs2 reads a corrupted file system image and degrades to read-only, the BUG_ON check for the buffer delay flag in submit_bh_wbc() may fail, causing a kernel bug.  This is because the buffer delay flag is not cleared when clearing the buffer state flags to discard a page/folio or a buffer head. So, fix this.  This became necessary when the use of nilfs2&#39;s own page clear routine was expanded.  This state inconsistency does not occur if the buffer is written normally by log writing.(CVE-2024-50116)In the Linux kernel, the following vulnerability has been resolved:  net: sched: fix use-after-free in taprio_change()  In &#39;taprio_change()&#39;, &#39;admin&#39; pointer may become dangling due to sched switch / removal caused by &#39;advance_sched()&#39;, and critical section protected by &#39;q-&gt;current_entry_lock&#39; is too small to prevent from such a scenario (which causes use-after-free detected by KASAN). Fix this by prefer &#39;rcu_replace_pointer()&#39; over &#39;rcu_assign_pointer()&#39; to update &#39;admin&#39; immediately before an attempt to schedule freeing.(CVE-2024-50127)In the Linux kernel, the following vulnerability has been resolved:  drm/vboxvideo: Replace fake VLA at end of vbva_mouse_pointer_shape with real VLA  Replace the fake VLA at end of the vbva_mouse_pointer_shape shape with a real VLA to fix a &#34;memcpy: detected field-spanning write error&#34; warning:  [   13.319813] memcpy: detected field-spanning write (size 16896) of single field &#34;p-&gt;data&#34; at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 (size 4) [   13.319841] WARNING: CPU: 0 PID: 1105 at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 hgsmi_update_pointer_shape+0x192/0x1c0 [vboxvideo] [   13.320038] Call Trace: [   13.320173]  hgsmi_update_pointer_shape [vboxvideo] [   13.320184]  vbox_cursor_atomic_update [vboxvideo]  Note as mentioned in the added comment it seems the original length calculation for the allocated and send hgsmi buffer is 4 bytes too large. Changing this is not the goal of this patch, so this behavior is kept.(CVE-2024-50134)In the Linux kernel, the following vulnerability has been resolved:  drm/vc4: Stop the active perfmon before being destroyed  Upon closing the file descriptor, the active performance monitor is not stopped. Although all perfmons are destroyed in `vc4_perfmon_close_file()`, the active performance monitor&#39;s pointer (`vc4-&gt;active_perfmon`) is still retained.  If we open a new file descriptor and submit a few jobs with performance monitors, the driver will attempt to stop the active performance monitor using the stale pointer in `vc4-&gt;active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed.  To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it.(CVE-2024-50187)In the Linux kernel, the following vulnerability has been resolved:  drm/radeon: Fix encoder-&gt;possible_clones  Include the encoder itself in its possible_clones bitmask. In the past nothing validated that drivers were populating possible_clones correctly, but that changed in commit 74d2aacbe840 (&#34;drm: Validate encoder-&gt;possible_clones&#34;). Looks like radeon never got the memo and is still not following the rules 100% correctly.  This results in some warnings during driver initialization: Bogus possible_clones: [ENCODER:46:TV-46] possible_clones=0x4 (full encoder mask=0x7) WARNING: CPU: 0 PID: 170 at drivers/gpu/drm/drm_mode_config.c:615 drm_mode_config_validate+0x113/0x39c ...  (cherry picked from commit 3b6e7d40649c0d75572039aff9d0911864c689db)(CVE-2024-50201)In the Linux kernel, the following vulnerability has been resolved:  USB: serial: io_edgeport: fix use after free in debug printk  The &#34;dev_dbg(&amp;urb-&gt;dev-&gt;dev, ...&#34; which happens after usb_free_urb(urb) is a use after free of the &#34;urb&#34; pointer.  Store the &#34;dev&#34; pointer at the start of the function to avoid this issue.(CVE-2024-50267)In the Linux kernel, the following vulnerability has been resolved:  filemap: Fix bounds checking in filemap_read()  If the caller supplies an iocb-&gt;ki_pos value that is close to the filesystem upper limit, and an iterator with a count that causes us to overflow that limit, then filemap_read() enters an infinite loop.  This behaviour was discovered when testing xfstests generic/525 with the &#34;localio&#34; optimisation for loopback NFS mounts.(CVE-2024-50272)In the Linux kernel, the following vulnerability has been resolved:  dm cache: fix potential out-of-bounds access on the first resume  Out-of-bounds access occurs if the fast device is expanded unexpectedly before the first-time resume of the cache table. This happens because expanding the fast device requires reloading the cache table for cache_create to allocate new in-core data structures that fit the new size, and the check in cache_preresume is not performed during the first resume, leading to the issue.  Reproduce steps:  1. prepare component devices:  dmsetup create cmeta --table &#34;0 8192 linear /dev/sdc 0&#34; dmsetup create cdata --table &#34;0 65536 linear /dev/sdc 8192&#34; dmsetup create corig --table &#34;0 524288 linear /dev/sdc 262144&#34; dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct  2. load a cache table of 512 cache blocks, and deliberately expand the    fast device before resuming the cache, making the in-core data    structures inadequate.  dmsetup create cache --notable dmsetup reload cache --table &#34;0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0&#34; dmsetup reload cdata --table &#34;0 131072 linear /dev/sdc 8192&#34; dmsetup resume cdata dmsetup resume cache  3. suspend the cache to write out the in-core dirty bitset and hint    array, leading to out-of-bounds access to the dirty bitset at offset    0x40:  dmsetup suspend cache  KASAN reports:    BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80   Read of size 8 at addr ffffc90000085040 by task dmsetup/90    (...snip...)   The buggy address belongs to the virtual mapping at    [ffffc90000085000, ffffc90000087000) created by:    cache_ctr+0x176a/0x35f0    (...snip...)   Memory state around the buggy address:    ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8    ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8   &gt;ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8                                              ^    ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8    ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8  Fix by checking the size change on the first resume.(CVE-2024-50278)In the Linux kernel, the following vulnerability has been resolved:  media: cx24116: prevent overflows on SNR calculus  as reported by Coverity, if reading SNR registers fail, a negative number will be returned, causing an underflow when reading SNR registers.  Prevent that.(CVE-2024-50290)In the Linux kernel, the following vulnerability has been resolved:  ASoC: stm32: spdifrx: fix dma channel release in stm32_spdifrx_remove  In case of error when requesting ctrl_chan DMA channel, ctrl_chan is not null. So the release of the dma channel leads to the following issue: [    4.879000] st,stm32-spdifrx 500d0000.audio-controller: dma_request_slave_channel error -19 [    4.888975] Unable to handle kernel NULL pointer dereference at virtual address 000000000000003d [...] [    5.096577] Call trace: [    5.099099]  dma_release_channel+0x24/0x100 [    5.103235]  stm32_spdifrx_remove+0x24/0x60 [snd_soc_stm32_spdifrx] [    5.109494]  stm32_spdifrx_probe+0x320/0x4c4 [snd_soc_stm32_spdifrx]  To avoid this issue, release channel only if the pointer is valid.(CVE-2024-50292)In the Linux kernel, the following vulnerability has been resolved:  HID: core: zero-initialize the report buffer  Since the report buffer is used by all kinds of drivers in various ways, let&#39;s zero-initialize it during allocation to make sure that it can&#39;t be ever used to leak kernel memory via specially-crafted report.(CVE-2024-50302)In the Linux kernel, the following vulnerability has been resolved:  media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in uvc_parse_format  This can lead to out of bounds writes since frames of this type were not taken into account when calculating the size of the frames buffer in uvc_parse_streaming.(CVE-2024-53104)In the Linux kernel, the following vulnerability has been resolved:  vp_vdpa: fix id_table array not null terminated error  Allocate one extra virtio_device_id as null terminator, otherwise vdpa_mgmtdev_get_classes() may iterate multiple times and visit undefined memory.(CVE-2024-53110)In the Linux kernel, the following vulnerability has been resolved:  ocfs2: uncache inode which has failed entering the group  Syzbot has reported the following BUG:  kernel BUG at fs/ocfs2/uptodate.c:509! ... Call Trace:  &lt;TASK&gt;  ? __die_body+0x5f/0xb0  ? die+0x9e/0xc0  ? do_trap+0x15a/0x3a0  ? ocfs2_set_new_buffer_uptodate+0x145/0x160  ? do_error_trap+0x1dc/0x2c0  ? ocfs2_set_new_buffer_uptodate+0x145/0x160  ? __pfx_do_error_trap+0x10/0x10  ? handle_invalid_op+0x34/0x40  ? ocfs2_set_new_buffer_uptodate+0x145/0x160  ? exc_invalid_op+0x38/0x50  ? asm_exc_invalid_op+0x1a/0x20  ? ocfs2_set_new_buffer_uptodate+0x2e/0x160  ? ocfs2_set_new_buffer_uptodate+0x144/0x160  ? ocfs2_set_new_buffer_uptodate+0x145/0x160  ocfs2_group_add+0x39f/0x15a0  ? __pfx_ocfs2_group_add+0x10/0x10  ? __pfx_lock_acquire+0x10/0x10  ? mnt_get_write_access+0x68/0x2b0  ? __pfx_lock_release+0x10/0x10  ? rcu_read_lock_any_held+0xb7/0x160  ? __pfx_rcu_read_lock_any_held+0x10/0x10  ? smack_log+0x123/0x540  ? mnt_get_write_access+0x68/0x2b0  ? mnt_get_write_access+0x68/0x2b0  ? mnt_get_write_access+0x226/0x2b0  ocfs2_ioctl+0x65e/0x7d0  ? __pfx_ocfs2_ioctl+0x10/0x10  ? smack_file_ioctl+0x29e/0x3a0  ? __pfx_smack_file_ioctl+0x10/0x10  ? lockdep_hardirqs_on_prepare+0x43d/0x780  ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10  ? __pfx_ocfs2_ioctl+0x10/0x10  __se_sys_ioctl+0xfb/0x170  do_syscall_64+0xf3/0x230  entry_SYSCALL_64_after_hwframe+0x77/0x7f ...  &lt;/TASK&gt;  When &#39;ioctl(OCFS2_IOC_GROUP_ADD, ...)&#39; has failed for the particular inode in &#39;ocfs2_verify_group_and_input()&#39;, corresponding buffer head remains cached and subsequent call to the same &#39;ioctl()&#39; for the same inode issues the BUG() in &#39;ocfs2_set_new_buffer_uptodate()&#39; (trying to cache the same buffer head of that inode). Fix this by uncaching the buffer head with &#39;ocfs2_remove_from_cache()&#39; on error path in &#39;ocfs2_group_add()&#39;.(CVE-2024-53112)In the Linux kernel, the following vulnerability has been resolved:  bpf: sync_linked_regs() must preserve subreg_def  Range propagation must not affect subreg_def marks, otherwise the following example is rewritten by verifier incorrectly when BPF_F_TEST_RND_HI32 flag is set:    0: call bpf_ktime_get_ns                   call bpf_ktime_get_ns   1: r0 &amp;= 0x7fffffff       after verifier   r0 &amp;= 0x7fffffff   2: w1 = w0                rewrites         w1 = w0   3: if w0 &lt; 10 goto +0     --------------&gt;  r11 = 0x2f5674a6     (r)   4: r1 &gt;&gt;= 32                               r11 &lt;&lt;= 32           (r)   5: r0 = r1                                 r1 |= r11            (r)   6: exit;                                   if w0 &lt; 0xa goto pc+0                                              r1 &gt;&gt;= 32                                              r0 = r1                                              exit  (or zero extension of w1 at (2) is missing for architectures that  require zero extension for upper register half).  The following happens w/o this patch: - r0 is marked as not a subreg at (0); - w1 is marked as subreg at (2); - w1 subreg_def is overridden at (3) by copy_register_state(); - w1 is read at (5) but mark_insn_zext() does not mark (2)   for zero extension, because w1 subreg_def is not set; - because of BPF_F_TEST_RND_HI32 flag verifier inserts random   value for hi32 bits of (2) (marked (r)); - this random value is read at (5).(CVE-2024-53125)In the Linux kernel, the following vulnerability has been resolved:  nilfs2: fix null-ptr-deref in block_dirty_buffer tracepoint  When using the &#34;block:block_dirty_buffer&#34; tracepoint, mark_buffer_dirty() may cause a NULL pointer dereference, or a general protection fault when KASAN is enabled.  This happens because, since the tracepoint was added in mark_buffer_dirty(), it references the dev_t member bh-&gt;b_bdev-&gt;bd_dev regardless of whether the buffer head has a pointer to a block_device structure.  In the current implementation, nilfs_grab_buffer(), which grabs a buffer to read (or create) a block of metadata, including b-tree node blocks, does not set the block device, but instead does so only if the buffer is not in the &#34;uptodate&#34; state for each of its caller block reading functions.  However, if the uptodate flag is set on a folio/page, and the buffer heads are detached from it by try_to_free_buffers(), and new buffer heads are then attached by create_empty_buffers(), the uptodate flag may be restored to each buffer without the block device being set to bh-&gt;b_bdev, and mark_buffer_dirty() may be called later in that state, resulting in the bug mentioned above.  Fix this issue by making nilfs_grab_buffer() always set the block device of the super block structure to the buffer head, regardless of the state of the buffer&#39;s uptodate flag.(CVE-2024-53130)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="bpftool" release="240.0.0.139.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-240.0.0.139.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="240.0.0.139.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-240.0.0.139.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="240.0.0.139.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-240.0.0.139.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="240.0.0.139.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-240.0.0.139.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="240.0.0.139.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-240.0.0.139.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="240.0.0.139.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-240.0.0.139.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="240.0.0.139.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-240.0.0.139.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="240.0.0.139.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-240.0.0.139.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="240.0.0.139.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-240.0.0.139.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="240.0.0.139.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-240.0.0.139.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="240.0.0.139.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-240.0.0.139.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="240.0.0.139.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-240.0.0.139.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="240.0.0.139.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-240.0.0.139.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="240.0.0.139.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-240.0.0.139.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="240.0.0.139.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-240.0.0.139.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="240.0.0.139.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-240.0.0.139.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="240.0.0.139.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-240.0.0.139.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="240.0.0.139.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-240.0.0.139.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="240.0.0.139.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-240.0.0.139.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="240.0.0.139.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-240.0.0.139.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="240.0.0.139.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-240.0.0.139.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="240.0.0.139.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-240.0.0.139.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="240.0.0.139.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-240.0.0.139.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="240.0.0.139.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-240.0.0.139.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="240.0.0.139.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-240.0.0.139.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="240.0.0.139.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-240.0.0.139.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="240.0.0.139.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-240.0.0.139.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="240.0.0.139.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-240.0.0.139.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="240.0.0.139.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-240.0.0.139.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="240.0.0.139.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-240.0.0.139.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2538</id>
          <title>An update for subversion is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2024-12-13"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46901" id="CVE-2024-46901" title="CVE-2024-46901" type="cve"></reference>
          </references>
          <description>mod_dav_svn denial-of-service via control characters in paths(CVE-2024-46901)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="perl-subversion" release="5.oe2203sp4" version="1.14.2">
                         <filename>perl-subversion-1.14.2-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-subversion" release="5.oe2203sp4" version="1.14.2">
                         <filename>python3-subversion-1.14.2-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ruby-subversion" release="5.oe2203sp4" version="1.14.2">
                         <filename>ruby-subversion-1.14.2-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="subversion" release="5.oe2203sp4" version="1.14.2">
                         <filename>subversion-1.14.2-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="subversion-debuginfo" release="5.oe2203sp4" version="1.14.2">
                         <filename>subversion-debuginfo-1.14.2-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="subversion-debugsource" release="5.oe2203sp4" version="1.14.2">
                         <filename>subversion-debugsource-1.14.2-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="subversion-devel" release="5.oe2203sp4" version="1.14.2">
                         <filename>subversion-devel-1.14.2-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="subversion-help" release="5.oe2203sp4" version="1.14.2">
                         <filename>subversion-help-1.14.2-5.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perl-subversion" release="5.oe2203sp4" version="1.14.2">
                         <filename>perl-subversion-1.14.2-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-subversion" release="5.oe2203sp4" version="1.14.2">
                         <filename>python3-subversion-1.14.2-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby-subversion" release="5.oe2203sp4" version="1.14.2">
                         <filename>ruby-subversion-1.14.2-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="subversion" release="5.oe2203sp4" version="1.14.2">
                         <filename>subversion-1.14.2-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="subversion-debuginfo" release="5.oe2203sp4" version="1.14.2">
                         <filename>subversion-debuginfo-1.14.2-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="subversion-debugsource" release="5.oe2203sp4" version="1.14.2">
                         <filename>subversion-debugsource-1.14.2-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="subversion-devel" release="5.oe2203sp4" version="1.14.2">
                         <filename>subversion-devel-1.14.2-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2540</id>
          <title>An update for python-django is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2024-12-13"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53907" id="CVE-2024-53907" title="CVE-2024-53907" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53908" id="CVE-2024-53908" title="CVE-2024-53908" type="cve"></reference>
          </references>
          <description>A vulnerability was found in the Django Web Framework. The strip_tags() and stripbtags template filter may be vulnerable to a potential denial of service (DoS) in cases of a large sequence of nested incomplete HTML entities.(CVE-2024-53907)A vulnerability was found in the Django Web Framework. The direct usage of django.db.models.fields.json.HasKey may be vulnerable to SQL injection if untrusted data is used to perform queries.(CVE-2024-53908)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="python-django-help" release="3.oe2203sp4" version="4.2.15">
                         <filename>python-django-help-4.2.15-3.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-Django" release="3.oe2203sp4" version="4.2.15">
                         <filename>python3-Django-4.2.15-3.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2547</id>
          <title>An update for haproxy is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-12-13"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53008" id="CVE-2024-53008" title="CVE-2024-53008" type="cve"></reference>
          </references>
          <description>Inconsistent interpretation of HTTP requests (&#39;HTTP Request/Response Smuggling&#39;) issue exists in HAProxy. If this vulnerability is exploited,  a remote attacker may access a path that is restricted by ACL (Access Control List) set on the product. As a result, the attacker may obtain sensitive information.(CVE-2024-53008)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="haproxy" release="14.oe2203sp4" version="2.6.6">
                         <filename>haproxy-2.6.6-14.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="haproxy-debuginfo" release="14.oe2203sp4" version="2.6.6">
                         <filename>haproxy-debuginfo-2.6.6-14.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="haproxy-debugsource" release="14.oe2203sp4" version="2.6.6">
                         <filename>haproxy-debugsource-2.6.6-14.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="haproxy-help" release="14.oe2203sp4" version="2.6.6">
                         <filename>haproxy-help-2.6.6-14.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="haproxy" release="14.oe2203sp4" version="2.6.6">
                         <filename>haproxy-2.6.6-14.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="haproxy-debuginfo" release="14.oe2203sp4" version="2.6.6">
                         <filename>haproxy-debuginfo-2.6.6-14.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="haproxy-debugsource" release="14.oe2203sp4" version="2.6.6">
                         <filename>haproxy-debugsource-2.6.6-14.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2551</id>
          <title>An update for etcd is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2024-12-13"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24538" id="CVE-2023-24538" title="CVE-2023-24538" type="cve"></reference>
          </references>
          <description>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="etcd" release="6.oe2203sp4" version="3.4.14">
                         <filename>etcd-3.4.14-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="etcd" release="6.oe2203sp4" version="3.4.14">
                         <filename>etcd-3.4.14-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2554</id>
          <title>An update for ffmpeg is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2024-12-13"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35368" id="CVE-2024-35368" title="CVE-2024-35368" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36616" id="CVE-2024-36616" title="CVE-2024-36616" type="cve"></reference>
          </references>
          <description>FFmpeg n7.0 is affected by a Double Free via the rkmpp_retrieve_frame function within libavcodec/rkmppdec.c.(CVE-2024-35368)An integer overflow in the component /libavformat/westwood_vqa.c of FFmpeg n6.1.1 allows attackers to cause a denial of service in the application via a crafted VQA file.(CVE-2024-36616)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="ffmpeg" release="20.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-4.2.4-20.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ffmpeg-debuginfo" release="20.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-debuginfo-4.2.4-20.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ffmpeg-debugsource" release="20.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-debugsource-4.2.4-20.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ffmpeg-devel" release="20.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-devel-4.2.4-20.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ffmpeg-libs" release="20.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-libs-4.2.4-20.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libavdevice" release="20.oe2203sp4" version="4.2.4">
                         <filename>libavdevice-4.2.4-20.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg" release="20.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-4.2.4-20.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg-debuginfo" release="20.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-debuginfo-4.2.4-20.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg-debugsource" release="20.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-debugsource-4.2.4-20.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg-devel" release="20.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-devel-4.2.4-20.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg-libs" release="20.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-libs-4.2.4-20.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libavdevice" release="20.oe2203sp4" version="4.2.4">
                         <filename>libavdevice-4.2.4-20.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2557</id>
          <title>An update for docker is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-12-13"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36623" id="CVE-2024-36623" title="CVE-2024-36623" type="cve"></reference>
          </references>
          <description>moby v25.0.3 has a Race Condition vulnerability in the streamformatter package which can be used to trigger multiple concurrent write operations resulting in data corruption or application crashes.(CVE-2024-36623)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="2" arch="aarch64" name="docker-engine" release="345.oe2203sp4" version="18.09.0">
                         <filename>docker-engine-18.09.0-345.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="docker-engine-debuginfo" release="345.oe2203sp4" version="18.09.0">
                         <filename>docker-engine-debuginfo-18.09.0-345.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="docker-engine-debugsource" release="345.oe2203sp4" version="18.09.0">
                         <filename>docker-engine-debugsource-18.09.0-345.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="docker-engine" release="345.oe2203sp4" version="18.09.0">
                         <filename>docker-engine-18.09.0-345.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="docker-engine-debuginfo" release="345.oe2203sp4" version="18.09.0">
                         <filename>docker-engine-debuginfo-18.09.0-345.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="docker-engine-debugsource" release="345.oe2203sp4" version="18.09.0">
                         <filename>docker-engine-debugsource-18.09.0-345.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2560</id>
          <title>An update for iptraf-ng is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-12-13"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-52949" id="CVE-2024-52949" title="CVE-2024-52949" type="cve"></reference>
          </references>
          <description>VUL-0: CVE-2024-52949: iptraf-ng: limit interface name lengths to IFNAMSIZ(CVE-2024-52949)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="iptraf-ng" release="4.oe2203sp4" version="1.2.1">
                         <filename>iptraf-ng-1.2.1-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="iptraf-ng-debuginfo" release="4.oe2203sp4" version="1.2.1">
                         <filename>iptraf-ng-debuginfo-1.2.1-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="iptraf-ng-debugsource" release="4.oe2203sp4" version="1.2.1">
                         <filename>iptraf-ng-debugsource-1.2.1-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="iptraf-ng-help" release="4.oe2203sp4" version="1.2.1">
                         <filename>iptraf-ng-help-1.2.1-4.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="iptraf-ng" release="4.oe2203sp4" version="1.2.1">
                         <filename>iptraf-ng-1.2.1-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="iptraf-ng-debuginfo" release="4.oe2203sp4" version="1.2.1">
                         <filename>iptraf-ng-debuginfo-1.2.1-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="iptraf-ng-debugsource" release="4.oe2203sp4" version="1.2.1">
                         <filename>iptraf-ng-debugsource-1.2.1-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2563</id>
          <title>An update for gstreamer1-plugins-base is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-12-20"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47538" id="CVE-2024-47538" title="CVE-2024-47538" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47541" id="CVE-2024-47541" title="CVE-2024-47541" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47542" id="CVE-2024-47542" title="CVE-2024-47542" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47600" id="CVE-2024-47600" title="CVE-2024-47600" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47607" id="CVE-2024-47607" title="CVE-2024-47607" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47615" id="CVE-2024-47615" title="CVE-2024-47615" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47835" id="CVE-2024-47835" title="CVE-2024-47835" type="cve"></reference>
          </references>
          <description>(CVE-2024-47538)(CVE-2024-47541)(CVE-2024-47542)(CVE-2024-47600)(CVE-2024-47607)(CVE-2024-47615)(CVE-2024-47835)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="gstreamer1-plugins-base" release="8.oe2203sp4" version="1.18.4">
                         <filename>gstreamer1-plugins-base-1.18.4-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gstreamer1-plugins-base-debuginfo" release="8.oe2203sp4" version="1.18.4">
                         <filename>gstreamer1-plugins-base-debuginfo-1.18.4-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gstreamer1-plugins-base-debugsource" release="8.oe2203sp4" version="1.18.4">
                         <filename>gstreamer1-plugins-base-debugsource-1.18.4-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gstreamer1-plugins-base-devel" release="8.oe2203sp4" version="1.18.4">
                         <filename>gstreamer1-plugins-base-devel-1.18.4-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="gstreamer1-plugins-base-help" release="8.oe2203sp4" version="1.18.4">
                         <filename>gstreamer1-plugins-base-help-1.18.4-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gstreamer1-plugins-base" release="8.oe2203sp4" version="1.18.4">
                         <filename>gstreamer1-plugins-base-1.18.4-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gstreamer1-plugins-base-debuginfo" release="8.oe2203sp4" version="1.18.4">
                         <filename>gstreamer1-plugins-base-debuginfo-1.18.4-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gstreamer1-plugins-base-debugsource" release="8.oe2203sp4" version="1.18.4">
                         <filename>gstreamer1-plugins-base-debugsource-1.18.4-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gstreamer1-plugins-base-devel" release="8.oe2203sp4" version="1.18.4">
                         <filename>gstreamer1-plugins-base-devel-1.18.4-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2564</id>
          <title>An update for tomcat is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2024-12-20"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50379" id="CVE-2024-50379" title="CVE-2024-50379" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-54677" id="CVE-2024-54677" title="CVE-2024-54677" type="cve"></reference>
          </references>
          <description>Time-of-check Time-of-use (TOCTOU) Race Condition vulnerability during JSP compilation in Apache Tomcat permits an RCE on case insensitive file systems when the default servlet is enabled for write (non-default configuration).  This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.1, from 10.1.0-M1 through 10.1.33, from 9.0.0.M1 through 9.0.97.  Users are recommended to upgrade to version 11.0.2, 10.1.34 or 9.0.08, which fixes the issue.(CVE-2024-50379)Uncontrolled Resource Consumption vulnerability in the examples web application provided with Apache Tomcat leads to denial of service.  This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.1, from 10.1.0-M1 through 10.1.33, from 9.0.0.M1 through 9.9.97.  Users are recommended to upgrade to version 11.0.2, 10.1.34 or 9.0.98, which fixes the issue.(CVE-2024-54677)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="noarch" name="tomcat" release="4.oe2203sp4" version="9.0.96">
                         <filename>tomcat-9.0.96-4.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="tomcat-help" release="4.oe2203sp4" version="9.0.96">
                         <filename>tomcat-help-9.0.96-4.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="tomcat-jsvc" release="4.oe2203sp4" version="9.0.96">
                         <filename>tomcat-jsvc-9.0.96-4.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2566</id>
          <title>An update for arm-trusted-firmware is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-12-20"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6285" id="CVE-2024-6285" title="CVE-2024-6285" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6287" id="CVE-2024-6287" title="CVE-2024-6287" type="cve"></reference>
          </references>
          <description>Integer Underflow (Wrap or Wraparound) vulnerability in Renesas arm-trusted-firmware. An integer underflow in image range check calculations could lead to bypassing address restrictions and loading of images to unallowed addresses.(CVE-2024-6285)Incorrect Calculation vulnerability in Renesas arm-trusted-firmware allows Local Execution of Code.When checking whether a new image invades/overlaps with a previously loaded image the code neglects to consider a few cases. that could An attacker to bypass memory range restriction and overwrite an already loaded image partly or completely, which could result in code execution and bypass of secure boot.(CVE-2024-6287)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="arm-trusted-firmware-armv8" release="6.oe2203sp4" version="2.3">
                         <filename>arm-trusted-firmware-armv8-2.3-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2571</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-12-20"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48868" id="CVE-2022-48868" title="CVE-2022-48868" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40927" id="CVE-2024-40927" title="CVE-2024-40927" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50218" id="CVE-2024-50218" title="CVE-2024-50218" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53114" id="CVE-2024-53114" title="CVE-2024-53114" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53142" id="CVE-2024-53142" title="CVE-2024-53142" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Let probe fail when workqueue cannot be enabledThe workqueue is enabled when the appropriate driver is loaded anddisabled when the driver is removed. When the driver is removed itassumes that the workqueue was enabled successfully and proceeds tofree allocations made during workqueue enabling.Failure during workqueue enabling does not prevent the driver frombeing loaded. This is because the error path within drv_enable_wq()returns success unless a second failure is encounteredduring the error path. By returning success it is possible to loadthe driver even if the workqueue cannot be enabled andallocations that do not exist are attempted to be freed duringdriver remove.Some examples of problematic flows:(a) idxd_dmaengine_drv_probe() -&gt; drv_enable_wq() -&gt; idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()-&gt;drv_disable_wq()-&gt;idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq().(b) idxd_dmaengine_drv_probe() -&gt; drv_enable_wq() -&gt; idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()-&gt;__idxd_wq_quiesce()-&gt;percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010Fix the drv_enable_wq() error path by returning the original error thatindicates failure of workqueue enabling. This ensures that the probefails when an error is encountered and the driver remove paths are onlyattempted when the workqueue was enabled successfully.(CVE-2022-48868)In the Linux kernel, the following vulnerability has been resolved:  xhci: Handle TD clearing for multiple streams case  When multiple streams are in use, multiple TDs might be in flight when an endpoint is stopped. We need to issue a Set TR Dequeue Pointer for each, to ensure everything is reset properly and the caches cleared. Change the logic so that any N&gt;1 TDs found active for different streams are deferred until after the first one is processed, calling xhci_invalidate_cancelled_tds() again from xhci_handle_cmd_set_deq() to queue another command until we are done with all of them. Also change the error/&#34;should never happen&#34; paths to ensure we at least clear any affected TDs, even if we can&#39;t issue a command to clear the hardware cache, and complain loudly with an xhci_warn() if this ever happens.  This problem case dates back to commit e9df17eb1408 (&#34;USB: xhci: Correct assumptions about number of rings per endpoint.&#34;) early on in the XHCI driver&#39;s life, when stream support was first added. It was then identified but not fixed nor made into a warning in commit 674f8438c121 (&#34;xhci: split handling halted endpoints into two steps&#34;), which added a FIXME comment for the problem case (without materially changing the behavior as far as I can tell, though the new logic made the problem more obvious).  Then later, in commit 94f339147fc3 (&#34;xhci: Fix failure to give back some cached cancelled URBs.&#34;), it was acknowledged again.  [Mathias: commit 94f339147fc3 (&#34;xhci: Fix failure to give back some cached cancelled URBs.&#34;) was a targeted regression fix to the previously mentioned patch. Users reported issues with usb stuck after unmounting/disconnecting UAS devices. This rolled back the TD clearing of multiple streams to its original state.]  Apparently the commit author was aware of the problem (yet still chose to submit it): It was still mentioned as a FIXME, an xhci_dbg() was added to log the problem condition, and the remaining issue was mentioned in the commit description. The choice of making the log type xhci_dbg() for what is, at this point, a completely unhandled and known broken condition is puzzling and unfortunate, as it guarantees that no actual users would see the log in production, thereby making it nigh undebuggable (indeed, even if you turn on DEBUG, the message doesn&#39;t really hint at there being a problem at all).  It took me *months* of random xHC crashes to finally find a reliable repro and be able to do a deep dive debug session, which could all have been avoided had this unhandled, broken condition been actually reported with a warning, as it should have been as a bug intentionally left in unfixed (never mind that it shouldn&#39;t have been left in at all).  &gt; Another fix to solve clearing the caches of all stream rings with &gt; cancelled TDs is needed, but not as urgent.  3 years after that statement and 14 years after the original bug was introduced, I think it&#39;s finally time to fix it. And maybe next time let&#39;s not leave bugs unfixed (that are actually worse than the original bug), and let&#39;s actually get people to review kernel commits please.  Fixes xHC crashes and IOMMU faults with UAS devices when handling errors/faults. Easiest repro is to use `hdparm` to mark an early sector (e.g. 1024) on a disk as bad, then `cat /dev/sdX &gt; /dev/null` in a loop. At least in the case of JMicron controllers, the read errors end up having to cancel two TDs (for two queued requests to different streams) and the one that didn&#39;t get cleared properly ends up faulting the xHC entirely when it tries to access DMA pages that have since been unmapped, referred to by the stale TDs. This normally happens quickly (after two or three loops). After this fix, I left the `cat` in a loop running overnight and experienced no xHC failures, with all read errors recovered properly. Repro&#39;d and tested on an Apple M1 Mac Mini (dwc3 host).  On systems without an IOMMU, this bug would instead silently corrupt freed memory, making this a ---truncated---(CVE-2024-40927)In the Linux kernel, the following vulnerability has been resolved:  ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow  Syzbot reported a kernel BUG in ocfs2_truncate_inline.  There are two reasons for this: first, the parameter value passed is greater than ocfs2_max_inline_data_with_xattr, second, the start and end parameters of ocfs2_truncate_inline are &#34;unsigned int&#34;.  So, we need to add a sanity check for byte_start and byte_len right before ocfs2_truncate_inline() in ocfs2_remove_inode_range(), if they are greater than ocfs2_max_inline_data_with_xattr return -EINVAL.(CVE-2024-50218)In the Linux kernel, the following vulnerability has been resolved:  x86/CPU/AMD: Clear virtualized VMLOAD/VMSAVE on Zen4 client  A number of Zen4 client SoCs advertise the ability to use virtualized VMLOAD/VMSAVE, but using these instructions is reported to be a cause of a random host reboot.  These instructions aren&#39;t intended to be advertised on Zen4 client so clear the capability.(CVE-2024-53114)In the Linux kernel, the following vulnerability has been resolved:  initramfs: avoid filename buffer overrun  The initramfs filename field is defined in Documentation/driver-api/early-userspace/buffer-format.rst as:   37 cpio_file := ALGN(4) + cpio_header + filename + &#34;\0&#34; + ALGN(4) + data ...  55 ============= ================== =========================  56 Field name    Field size         Meaning  57 ============= ================== ========================= ...  70 c_namesize    8 bytes            Length of filename, including final \0  When extracting an initramfs cpio archive, the kernel&#39;s do_name() path handler assumes a zero-terminated path at @collected, passing it directly to filp_open() / init_mkdir() / init_mknod().  If a specially crafted cpio entry carries a non-zero-terminated filename and is followed by uninitialized memory, then a file may be created with trailing characters that represent the uninitialized memory. The ability to create an initramfs entry would imply already having full control of the system, so the buffer overrun shouldn&#39;t be considered a security vulnerability.  Append the output of the following bash script to an existing initramfs and observe any created /initramfs_test_fname_overrunAA* path. E.g.   ./reproducer.sh | gzip &gt;&gt; /myinitramfs  It&#39;s easiest to observe non-zero uninitialized memory when the output is gzipped, as it&#39;ll overflow the heap allocated @out_buf in __gunzip(), rather than the initrd_start+initrd_size block.  ---- reproducer.sh ---- nilchar=&#34;A&#34; # change to &#34;\0&#34; to properly zero terminate / pad magic=&#34;070701&#34; ino=1 mode=$(( 0100777 )) uid=0 gid=0 nlink=1 mtime=1 filesize=0 devmajor=0 devminor=1 rdevmajor=0 rdevminor=0 csum=0 fname=&#34;initramfs_test_fname_overrun&#34; namelen=$(( ${#fname} + 1 )) # plus one to account for terminator  printf &#34;%s%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%s&#34; \  $magic $ino $mode $uid $gid $nlink $mtime $filesize \  $devmajor $devminor $rdevmajor $rdevminor $namelen $csum $fname  termpadlen=$(( 1 + ((4 - ((110 + $namelen) &amp; 3)) % 4) )) printf &#34;%.s${nilchar}&#34; $(seq 1 $termpadlen) ---- reproducer.sh ----  Symlink filename fields handled in do_symlink() won&#39;t overrun past the data segment, due to the explicit zero-termination of the symlink target.  Fix filename buffer overrun by aborting the initramfs FSM if any cpio entry doesn&#39;t carry a zero-terminator at the expected (name_len - 1) offset.(CVE-2024-53142)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="bpftool" release="242.0.0.141.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-242.0.0.141.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="242.0.0.141.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-242.0.0.141.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="242.0.0.141.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-242.0.0.141.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="242.0.0.141.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-242.0.0.141.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="242.0.0.141.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-242.0.0.141.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="242.0.0.141.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-242.0.0.141.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="242.0.0.141.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-242.0.0.141.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="242.0.0.141.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-242.0.0.141.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="242.0.0.141.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-242.0.0.141.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="242.0.0.141.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-242.0.0.141.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="242.0.0.141.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-242.0.0.141.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="242.0.0.141.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-242.0.0.141.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="242.0.0.141.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-242.0.0.141.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="242.0.0.141.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-242.0.0.141.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="242.0.0.141.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-242.0.0.141.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="242.0.0.141.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-242.0.0.141.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="242.0.0.141.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-242.0.0.141.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="242.0.0.141.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-242.0.0.141.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="242.0.0.141.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-242.0.0.141.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="242.0.0.141.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-242.0.0.141.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="242.0.0.141.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-242.0.0.141.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="242.0.0.141.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-242.0.0.141.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="242.0.0.141.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-242.0.0.141.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="242.0.0.141.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-242.0.0.141.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="242.0.0.141.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-242.0.0.141.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="242.0.0.141.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-242.0.0.141.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="242.0.0.141.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-242.0.0.141.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="242.0.0.141.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-242.0.0.141.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="242.0.0.141.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-242.0.0.141.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="242.0.0.141.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-242.0.0.141.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2578</id>
          <title>An update for ffmpeg is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-12-20"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36617" id="CVE-2024-36617" title="CVE-2024-36617" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36618" id="CVE-2024-36618" title="CVE-2024-36618" type="cve"></reference>
          </references>
          <description>FFmpeg n6.1.1 has an integer overflow vulnerability in the FFmpeg CAF decoder.(CVE-2024-36617)FFmpeg n6.1.1 has a vulnerability in the AVI demuxer of the libavformat library which allows for an integer overflow, potentially resulting in a denial-of-service (DoS) condition.(CVE-2024-36618)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="ffmpeg" release="21.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-4.2.4-21.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ffmpeg-debuginfo" release="21.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-debuginfo-4.2.4-21.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ffmpeg-debugsource" release="21.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-debugsource-4.2.4-21.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ffmpeg-devel" release="21.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-devel-4.2.4-21.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ffmpeg-libs" release="21.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-libs-4.2.4-21.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libavdevice" release="21.oe2203sp4" version="4.2.4">
                         <filename>libavdevice-4.2.4-21.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg" release="21.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-4.2.4-21.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg-debuginfo" release="21.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-debuginfo-4.2.4-21.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg-debugsource" release="21.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-debugsource-4.2.4-21.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg-devel" release="21.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-devel-4.2.4-21.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg-libs" release="21.oe2203sp4" version="4.2.4">
                         <filename>ffmpeg-libs-4.2.4-21.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libavdevice" release="21.oe2203sp4" version="4.2.4">
                         <filename>libavdevice-4.2.4-21.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2579</id>
          <title>An update for undertow is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-12-20"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4109" id="CVE-2024-4109" title="CVE-2024-4109" type="cve"></reference>
          </references>
          <description>Description: Product Security received a report that Undertow might incorrectly re-use an HTTP request header value from a previous stream for a request associated with a subsequent stream on the same HTTP/2 connection. The issue is linked to the readHpackString method and its interaction with the stringBuilder field. While such behavior typically results in an error followed by the termination of the HTTP/2 connection, it presents a potential vector for information leakage between requests.  The original reporter referenced a similar issue in Apache Tomcat (CVE-2020-17527). In the patch for that vulnerability (https://github.com/apache/tomcat/commit/8d2fe6894d6e258a6d615d7f786acca80e6020cb) a StringBuilder field was improperly reused across multiple requests, leading to this issue. In the io.undertow.protocols.http2.HpackDecoder class of Undertow, within the readHpackString method, there is a code pattern identical to the one mentioned:  ``` for (int i = 0; i &lt; length; ++i) { stringBuilder.append((char) buffer.get()); } String ret = stringBuilder.toString(); stringBuilder.setLength(0); if (ret.isEmpty()) { //return the interned empty string, rather than allocating a new one each time return &#34;&#34;; } ```  Steps to reproduce: No reproducers or PoC were provided, this issue was identified through static testing.   Affected versions:  2.2.x, 2.3.x, and 3.x(CVE-2024-4109)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="noarch" name="undertow" release="8.oe2203sp4" version="1.4.0">
                         <filename>undertow-1.4.0-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="undertow-javadoc" release="8.oe2203sp4" version="1.4.0">
                         <filename>undertow-javadoc-1.4.0-8.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2580</id>
          <title>An update for socat is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2024-12-27"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-54661" id="CVE-2024-54661" title="CVE-2024-54661" type="cve"></reference>
          </references>
          <description>readline.sh in socat through 1.8.0.1 relies on the /tmp/$USER/stderr2 file.(CVE-2024-54661)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="socat" release="9.oe2203sp4" version="1.7.3.2">
                         <filename>socat-1.7.3.2-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="socat-debuginfo" release="9.oe2203sp4" version="1.7.3.2">
                         <filename>socat-debuginfo-1.7.3.2-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="socat-debugsource" release="9.oe2203sp4" version="1.7.3.2">
                         <filename>socat-debugsource-1.7.3.2-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="socat-help" release="9.oe2203sp4" version="1.7.3.2">
                         <filename>socat-help-1.7.3.2-9.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="socat" release="9.oe2203sp4" version="1.7.3.2">
                         <filename>socat-1.7.3.2-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="socat-debuginfo" release="9.oe2203sp4" version="1.7.3.2">
                         <filename>socat-debuginfo-1.7.3.2-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="socat-debugsource" release="9.oe2203sp4" version="1.7.3.2">
                         <filename>socat-debugsource-1.7.3.2-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2583</id>
          <title>An update for tinyxml is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-12-27"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34194" id="CVE-2023-34194" title="CVE-2023-34194" type="cve"></reference>
          </references>
          <description>StringEqual in TiXmlDeclaration::Parse in tinyxmlparser.cpp in TinyXML through 2.6.2 has a reachable assertion (and application exit) via a crafted XML document with a &#39;\0&#39; located after whitespace.(CVE-2023-34194)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="tinyxml" release="24.oe2203sp4" version="2.6.2">
                         <filename>tinyxml-2.6.2-24.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="tinyxml-debuginfo" release="24.oe2203sp4" version="2.6.2">
                         <filename>tinyxml-debuginfo-2.6.2-24.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="tinyxml-debugsource" release="24.oe2203sp4" version="2.6.2">
                         <filename>tinyxml-debugsource-2.6.2-24.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="tinyxml-devel" release="24.oe2203sp4" version="2.6.2">
                         <filename>tinyxml-devel-2.6.2-24.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="tinyxml" release="24.oe2203sp4" version="2.6.2">
                         <filename>tinyxml-2.6.2-24.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="tinyxml-debuginfo" release="24.oe2203sp4" version="2.6.2">
                         <filename>tinyxml-debuginfo-2.6.2-24.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="tinyxml-debugsource" release="24.oe2203sp4" version="2.6.2">
                         <filename>tinyxml-debugsource-2.6.2-24.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="tinyxml-devel" release="24.oe2203sp4" version="2.6.2">
                         <filename>tinyxml-devel-2.6.2-24.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2584</id>
          <title>An update for libspf2 is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-12-27"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-42118" id="CVE-2023-42118" title="CVE-2023-42118" type="cve"></reference>
          </references>
          <description>Exim libspf2 Integer Underflow Remote Code Execution Vulnerability. This vulnerability allows network-adjacent attackers to execute arbitrary code on affected installations of Exim libspf2. Authentication is not required to exploit this vulnerability. The specific flaw exists within the parsing of SPF macros. When parsing SPF macros, the process does not properly validate user-supplied data, which can result in an integer underflow before writing to memory. An attacker can leverage this vulnerability to execute code in the context of the service account.. Was ZDI-CAN-17578.(CVE-2023-42118)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libspf2" release="2.oe2203sp4" version="1.2.11">
                         <filename>libspf2-1.2.11-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libspf2-debuginfo" release="2.oe2203sp4" version="1.2.11">
                         <filename>libspf2-debuginfo-1.2.11-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libspf2-debugsource" release="2.oe2203sp4" version="1.2.11">
                         <filename>libspf2-debugsource-1.2.11-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libspf2-devel" release="2.oe2203sp4" version="1.2.11">
                         <filename>libspf2-devel-1.2.11-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libspf2-progs" release="2.oe2203sp4" version="1.2.11">
                         <filename>libspf2-progs-1.2.11-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perl-Mail-SPF_XS" release="2.oe2203sp4" version="1.2.11">
                         <filename>perl-Mail-SPF_XS-1.2.11-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="libspf2-apidocs" release="2.oe2203sp4" version="1.2.11">
                         <filename>libspf2-apidocs-1.2.11-2.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libspf2" release="2.oe2203sp4" version="1.2.11">
                         <filename>libspf2-1.2.11-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libspf2-debuginfo" release="2.oe2203sp4" version="1.2.11">
                         <filename>libspf2-debuginfo-1.2.11-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libspf2-debugsource" release="2.oe2203sp4" version="1.2.11">
                         <filename>libspf2-debugsource-1.2.11-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libspf2-devel" release="2.oe2203sp4" version="1.2.11">
                         <filename>libspf2-devel-1.2.11-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libspf2-progs" release="2.oe2203sp4" version="1.2.11">
                         <filename>libspf2-progs-1.2.11-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perl-Mail-SPF_XS" release="2.oe2203sp4" version="1.2.11">
                         <filename>perl-Mail-SPF_XS-1.2.11-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2587</id>
          <title>An update for golang is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-12-27"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-34155" id="CVE-2024-34155" title="CVE-2024-34155" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-34156" id="CVE-2024-34156" title="CVE-2024-34156" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-34158" id="CVE-2024-34158" title="CVE-2024-34158" type="cve"></reference>
          </references>
          <description>Calling any of the Parse functions on Go source code which contains deeply nested literals can cause a panic due to stack exhaustion.(CVE-2024-34155)Calling Decoder.Decode on a message which contains deeply nested structures can cause a panic due to stack exhaustion. This is a follow-up to CVE-2022-30635.(CVE-2024-34156)Calling Parse on a &#34;// +build&#34; build tag line with deeply nested expressions can cause a panic due to stack exhaustion.(CVE-2024-34158)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="golang" release="37.oe2203sp4" version="1.17.3">
                         <filename>golang-1.17.3-37.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="golang-devel" release="37.oe2203sp4" version="1.17.3">
                         <filename>golang-devel-1.17.3-37.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="golang-help" release="37.oe2203sp4" version="1.17.3">
                         <filename>golang-help-1.17.3-37.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="golang" release="37.oe2203sp4" version="1.17.3">
                         <filename>golang-1.17.3-37.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2591</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-12-27"></issued>
          <references>
               <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-53095" id="CVE-2024-53095" title="CVE-2024-53095" type="cve"></reference>
          </references>
          <description>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:  smb: client: Fix use-after-free of network namespace.  Recently, we got a customer report that CIFS triggers oops while reconnecting to a server.  [0]  The workload runs on Kubernetes, and some pods mount CIFS servers in non-root network namespaces.  The problem rarely happened, but it was always while the pod was dying.  The root cause is wrong reference counting for network namespace.  CIFS uses kernel sockets, which do not hold refcnt of the netns that the socket belongs to.  That means CIFS must ensure the socket is always freed before its netns; otherwise, use-after-free happens.  The repro steps are roughly:    1. mount CIFS in a non-root netns   2. drop packets from the netns   3. destroy the netns   4. unmount CIFS  We can reproduce the issue quickly with the script [1] below and see the splat [2] if CONFIG_NET_NS_REFCNT_TRACKER is enabled.  When the socket is TCP, it is hard to guarantee the netns lifetime without holding refcnt due to async timers.  Let&#39;s hold netns refcnt for each socket as done for SMC in commit 9744d2bf1976 (&#34;smc: Fix use-after-free in tcp_write_timer_handler().&#34;).  Note that we need to move put_net() from cifs_put_tcp_session() to clean_demultiplex_info(); otherwise, __sock_create() still could touch a freed netns while cifsd tries to reconnect from cifs_demultiplex_thread().  Also, maybe_get_net() cannot be put just before __sock_create() because the code is not under RCU and there is a small chance that the same address happened to be reallocated to another netns.  [0]: CIFS: VFS: \\XXXXXXXXXXX has not responded in 15 seconds. Reconnecting... CIFS: Serverclose failed 4 times, giving up Unable to handle kernel paging request at virtual address 14de99e461f84a07 Mem abort info:   ESR = 0x0000000096000004   EC = 0x25: DABT (current EL), IL = 32 bits   SET = 0, FnV = 0   EA = 0, S1PTW = 0   FSC = 0x04: level 0 translation fault Data abort info:   ISV = 0, ISS = 0x00000004   CM = 0, WnR = 0 [14de99e461f84a07] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: cls_bpf sch_ingress nls_utf8 cifs cifs_arc4 cifs_md4 dns_resolver tcp_diag inet_diag veth xt_state xt_connmark nf_conntrack_netlink xt_nat xt_statistic xt_MASQUERADE xt_mark xt_addrtype ipt_REJECT nf_reject_ipv4 nft_chain_nat nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_comment nft_compat nf_tables nfnetlink overlay nls_ascii nls_cp437 sunrpc vfat fat aes_ce_blk aes_ce_cipher ghash_ce sm4_ce_cipher sm4 sm3_ce sm3 sha3_ce sha512_ce sha512_arm64 sha1_ce ena button sch_fq_codel loop fuse configfs dmi_sysfs sha2_ce sha256_arm64 dm_mirror dm_region_hash dm_log dm_mod dax efivarfs CPU: 5 PID: 2690970 Comm: cifsd Not tainted 6.1.103-109.184.amzn2023.aarch64 #1 Hardware name: Amazon EC2 r7g.4xlarge/, BIOS 1.0 11/1/2018 pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : fib_rules_lookup+0x44/0x238 lr : __fib_lookup+0x64/0xbc sp : ffff8000265db790 x29: ffff8000265db790 x28: 0000000000000000 x27: 000000000000bd01 x26: 0000000000000000 x25: ffff000b4baf8000 x24: ffff00047b5e4580 x23: ffff8000265db7e0 x22: 0000000000000000 x21: ffff00047b5e4500 x20: ffff0010e3f694f8 x19: 14de99e461f849f7 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 3f92800abd010002 x11: 0000000000000001 x10: ffff0010e3f69420 x9 : ffff800008a6f294 x8 : 0000000000000000 x7 : 0000000000000006 x6 : 0000000000000000 x5 : 0000000000000001 x4 : ffff001924354280 x3 : ffff8000265db7e0 x2 : 0000000000000000 x1 : ffff0010e3f694f8 x0 : ffff00047b5e4500 Call trace:  fib_rules_lookup+0x44/0x238  __fib_lookup+0x64/0xbc  ip_route_output_key_hash_rcu+0x2c4/0x398  ip_route_output_key_hash+0x60/0x8c  tcp_v4_connect+0x290/0x488  __inet_stream_connect+0x108/0x3d0  inet_stream_connect+0x50/0x78  kernel_connect+0x6c/0xac  generic_ip_conne ---truncated---(CVE-2024-53095)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="bpftool" release="243.0.0.142.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-243.0.0.142.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="243.0.0.142.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-243.0.0.142.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="243.0.0.142.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-243.0.0.142.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="243.0.0.142.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-243.0.0.142.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="243.0.0.142.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-243.0.0.142.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="243.0.0.142.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-243.0.0.142.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="243.0.0.142.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-243.0.0.142.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="243.0.0.142.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-243.0.0.142.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="243.0.0.142.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-243.0.0.142.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="243.0.0.142.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-243.0.0.142.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="243.0.0.142.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-243.0.0.142.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="243.0.0.142.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-243.0.0.142.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="243.0.0.142.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-243.0.0.142.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="243.0.0.142.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-243.0.0.142.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="243.0.0.142.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-243.0.0.142.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="243.0.0.142.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-243.0.0.142.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="243.0.0.142.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-243.0.0.142.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="243.0.0.142.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-243.0.0.142.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="243.0.0.142.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-243.0.0.142.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="243.0.0.142.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-243.0.0.142.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="243.0.0.142.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-243.0.0.142.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="243.0.0.142.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-243.0.0.142.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="243.0.0.142.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-243.0.0.142.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="243.0.0.142.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-243.0.0.142.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="243.0.0.142.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-243.0.0.142.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="243.0.0.142.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-243.0.0.142.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="243.0.0.142.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-243.0.0.142.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="243.0.0.142.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-243.0.0.142.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="243.0.0.142.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-243.0.0.142.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="243.0.0.142.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-243.0.0.142.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2592</id>
          <title>An update for gstreamer1-plugins-good is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2024-12-27"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47537" id="CVE-2024-47537" title="CVE-2024-47537" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47539" id="CVE-2024-47539" title="CVE-2024-47539" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47540" id="CVE-2024-47540" title="CVE-2024-47540" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47543" id="CVE-2024-47543" title="CVE-2024-47543" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47544" id="CVE-2024-47544" title="CVE-2024-47544" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47545" id="CVE-2024-47545" title="CVE-2024-47545" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47546" id="CVE-2024-47546" title="CVE-2024-47546" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47596" id="CVE-2024-47596" title="CVE-2024-47596" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47597" id="CVE-2024-47597" title="CVE-2024-47597" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47599" id="CVE-2024-47599" title="CVE-2024-47599" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47601" id="CVE-2024-47601" title="CVE-2024-47601" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47602" id="CVE-2024-47602" title="CVE-2024-47602" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47603" id="CVE-2024-47603" title="CVE-2024-47603" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47606" id="CVE-2024-47606" title="CVE-2024-47606" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47613" id="CVE-2024-47613" title="CVE-2024-47613" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47774" id="CVE-2024-47774" title="CVE-2024-47774" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47775" id="CVE-2024-47775" title="CVE-2024-47775" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47776" id="CVE-2024-47776" title="CVE-2024-47776" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47777" id="CVE-2024-47777" title="CVE-2024-47777" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47778" id="CVE-2024-47778" title="CVE-2024-47778" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47834" id="CVE-2024-47834" title="CVE-2024-47834" type="cve"></reference>
          </references>
          <description>(CVE-2024-47537)(CVE-2024-47539)(CVE-2024-47540)(CVE-2024-47543)(CVE-2024-47544)(CVE-2024-47545)(CVE-2024-47546)(CVE-2024-47596)(CVE-2024-47597)(CVE-2024-47599)(CVE-2024-47601)(CVE-2024-47602)(CVE-2024-47603)(CVE-2024-47606)(CVE-2024-47613)(CVE-2024-47774)(CVE-2024-47775)(CVE-2024-47776)(CVE-2024-47777)(CVE-2024-47778)(CVE-2024-47834)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="gstreamer1-plugins-good" release="8.oe2203sp4" version="1.16.2">
                         <filename>gstreamer1-plugins-good-1.16.2-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gstreamer1-plugins-good-debuginfo" release="8.oe2203sp4" version="1.16.2">
                         <filename>gstreamer1-plugins-good-debuginfo-1.16.2-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gstreamer1-plugins-good-debugsource" release="8.oe2203sp4" version="1.16.2">
                         <filename>gstreamer1-plugins-good-debugsource-1.16.2-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gstreamer1-plugins-good-gtk" release="8.oe2203sp4" version="1.16.2">
                         <filename>gstreamer1-plugins-good-gtk-1.16.2-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="gstreamer1-plugins-good-help" release="8.oe2203sp4" version="1.16.2">
                         <filename>gstreamer1-plugins-good-help-1.16.2-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gstreamer1-plugins-good" release="8.oe2203sp4" version="1.16.2">
                         <filename>gstreamer1-plugins-good-1.16.2-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gstreamer1-plugins-good-debuginfo" release="8.oe2203sp4" version="1.16.2">
                         <filename>gstreamer1-plugins-good-debuginfo-1.16.2-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gstreamer1-plugins-good-debugsource" release="8.oe2203sp4" version="1.16.2">
                         <filename>gstreamer1-plugins-good-debugsource-1.16.2-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gstreamer1-plugins-good-gtk" release="8.oe2203sp4" version="1.16.2">
                         <filename>gstreamer1-plugins-good-gtk-1.16.2-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2597</id>
          <title>An update for python-jinja2 is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2024-12-27"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56326" id="CVE-2024-56326" title="CVE-2024-56326" type="cve"></reference>
          </references>
          <description>Jinja is an extensible templating engine. Prior to 3.1.5, An oversight in how the Jinja sandboxed environment detects calls to str.format allows an attacker that controls the content of a template to execute arbitrary Python code. To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates. Jinja&#39;s sandbox does catch calls to str.format and ensures they don&#39;t escape the sandbox. However, it&#39;s possible to store a reference to a malicious string&#39;s format method, then pass that to a filter that calls it. No such filters are built-in to Jinja, but could be present through custom filters in an application. After the fix, such indirect calls are also handled by the sandbox. This vulnerability is fixed in 3.1.5.(CVE-2024-56326)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="python-jinja2-help" release="5.oe2203sp4" version="3.0.3">
                         <filename>python-jinja2-help-3.0.3-5.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-jinja2" release="5.oe2203sp4" version="3.0.3">
                         <filename>python3-jinja2-3.0.3-5.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2599</id>
          <title>An update for dpdk is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-12-27"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-11614" id="CVE-2024-11614" title="CVE-2024-11614" type="cve"></reference>
          </references>
          <description>An out-of-bounds read vulnerability was found in DPDK&#39;s Vhost library checksum offload feature. This issue enables an untrusted or compromised guest to crash the hypervisor&#39;s vSwitch by forging Virtio descriptors to cause out-of-bounds reads. This flaw allows an attacker with a malicious VM using a virtio driver to cause the vhost-user side to crash by sending a packet with a Tx checksum offload request and an invalid csum_start offset.(CVE-2024-11614)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="dpdk" release="81.oe2203sp4" version="21.11">
                         <filename>dpdk-21.11-81.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="dpdk-debuginfo" release="81.oe2203sp4" version="21.11">
                         <filename>dpdk-debuginfo-21.11-81.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="dpdk-debugsource" release="81.oe2203sp4" version="21.11">
                         <filename>dpdk-debugsource-21.11-81.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="dpdk-devel" release="81.oe2203sp4" version="21.11">
                         <filename>dpdk-devel-21.11-81.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="dpdk-tools" release="81.oe2203sp4" version="21.11">
                         <filename>dpdk-tools-21.11-81.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="dpdk-doc" release="81.oe2203sp4" version="21.11">
                         <filename>dpdk-doc-21.11-81.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="dpdk" release="81.oe2203sp4" version="21.11">
                         <filename>dpdk-21.11-81.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="dpdk-debuginfo" release="81.oe2203sp4" version="21.11">
                         <filename>dpdk-debuginfo-21.11-81.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="dpdk-debugsource" release="81.oe2203sp4" version="21.11">
                         <filename>dpdk-debugsource-21.11-81.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="dpdk-devel" release="81.oe2203sp4" version="21.11">
                         <filename>dpdk-devel-21.11-81.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="dpdk-tools" release="81.oe2203sp4" version="21.11">
                         <filename>dpdk-tools-21.11-81.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2602</id>
          <title>An update for poppler is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-12-27"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56378" id="CVE-2024-56378" title="CVE-2024-56378" type="cve"></reference>
          </references>
          <description>libpoppler.so in Poppler through 24.12.0 has an out-of-bounds read vulnerability within the JBIG2Bitmap::combine function in JBIG2Stream.cc.(CVE-2024-56378)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="poppler" release="10.oe2203sp4" version="0.90.0">
                         <filename>poppler-0.90.0-10.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-cpp" release="10.oe2203sp4" version="0.90.0">
                         <filename>poppler-cpp-0.90.0-10.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-cpp-devel" release="10.oe2203sp4" version="0.90.0">
                         <filename>poppler-cpp-devel-0.90.0-10.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-debuginfo" release="10.oe2203sp4" version="0.90.0">
                         <filename>poppler-debuginfo-0.90.0-10.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-debugsource" release="10.oe2203sp4" version="0.90.0">
                         <filename>poppler-debugsource-0.90.0-10.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-devel" release="10.oe2203sp4" version="0.90.0">
                         <filename>poppler-devel-0.90.0-10.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-glib" release="10.oe2203sp4" version="0.90.0">
                         <filename>poppler-glib-0.90.0-10.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-glib-devel" release="10.oe2203sp4" version="0.90.0">
                         <filename>poppler-glib-devel-0.90.0-10.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-qt5" release="10.oe2203sp4" version="0.90.0">
                         <filename>poppler-qt5-0.90.0-10.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-qt5-devel" release="10.oe2203sp4" version="0.90.0">
                         <filename>poppler-qt5-devel-0.90.0-10.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-utils" release="10.oe2203sp4" version="0.90.0">
                         <filename>poppler-utils-0.90.0-10.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="poppler-glib-doc" release="10.oe2203sp4" version="0.90.0">
                         <filename>poppler-glib-doc-0.90.0-10.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="poppler-help" release="10.oe2203sp4" version="0.90.0">
                         <filename>poppler-help-0.90.0-10.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler" release="10.oe2203sp4" version="0.90.0">
                         <filename>poppler-0.90.0-10.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-cpp" release="10.oe2203sp4" version="0.90.0">
                         <filename>poppler-cpp-0.90.0-10.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-cpp-devel" release="10.oe2203sp4" version="0.90.0">
                         <filename>poppler-cpp-devel-0.90.0-10.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-debuginfo" release="10.oe2203sp4" version="0.90.0">
                         <filename>poppler-debuginfo-0.90.0-10.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-debugsource" release="10.oe2203sp4" version="0.90.0">
                         <filename>poppler-debugsource-0.90.0-10.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-devel" release="10.oe2203sp4" version="0.90.0">
                         <filename>poppler-devel-0.90.0-10.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-glib" release="10.oe2203sp4" version="0.90.0">
                         <filename>poppler-glib-0.90.0-10.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-glib-devel" release="10.oe2203sp4" version="0.90.0">
                         <filename>poppler-glib-devel-0.90.0-10.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-qt5" release="10.oe2203sp4" version="0.90.0">
                         <filename>poppler-qt5-0.90.0-10.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-qt5-devel" release="10.oe2203sp4" version="0.90.0">
                         <filename>poppler-qt5-devel-0.90.0-10.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-utils" release="10.oe2203sp4" version="0.90.0">
                         <filename>poppler-utils-0.90.0-10.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1007</id>
          <title>An update for python-jinja2 is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-01-03"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56201" id="CVE-2024-56201" title="CVE-2024-56201" type="cve"></reference>
          </references>
          <description>Jinja is an extensible templating engine. Prior to 3.1.5, a bug in the Jinja compiler allows an attacker that controls both the content and filename of a template to execute arbitrary Python code, regardless of if Jinja&#39;s sandbox is used. To exploit the vulnerability, an attacker needs to control both the filename and the contents of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates where the template author can also choose the template filename. This vulnerability is fixed in 3.1.5.(CVE-2024-56201)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="python-jinja2-help" release="6.oe2203sp4" version="3.0.3">
                         <filename>python-jinja2-help-3.0.3-6.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-jinja2" release="6.oe2203sp4" version="3.0.3">
                         <filename>python3-jinja2-3.0.3-6.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1013</id>
          <title>An update for hplip is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-01-03"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-6923" id="CVE-2020-6923" title="CVE-2020-6923" type="cve"></reference>
          </references>
          <description>The HP Linux Imaging and Printing (HPLIP) software may potentially be affected by memory buffer overflow.(CVE-2020-6923)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="hplip" release="2.oe2203sp4" version="3.23.8">
                         <filename>hplip-3.23.8-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hplip-debuginfo" release="2.oe2203sp4" version="3.23.8">
                         <filename>hplip-debuginfo-3.23.8-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hplip-debugsource" release="2.oe2203sp4" version="3.23.8">
                         <filename>hplip-debugsource-3.23.8-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hplip" release="2.oe2203sp4" version="3.23.8">
                         <filename>hplip-3.23.8-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hplip-debuginfo" release="2.oe2203sp4" version="3.23.8">
                         <filename>hplip-debuginfo-3.23.8-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hplip-debugsource" release="2.oe2203sp4" version="3.23.8">
                         <filename>hplip-debugsource-3.23.8-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1014</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-01-03"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49856" id="CVE-2024-49856" title="CVE-2024-49856" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50086" id="CVE-2024-50086" title="CVE-2024-50086" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50287" id="CVE-2024-50287" title="CVE-2024-50287" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53150" id="CVE-2024-53150" title="CVE-2024-53150" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56630" id="CVE-2024-56630" title="CVE-2024-56630" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:  x86/sgx: Fix deadlock in SGX NUMA node search  When the current node doesn&#39;t have an EPC section configured by firmware and all other EPC sections are used up, CPU can get stuck inside the while loop that looks for an available EPC page from remote nodes indefinitely, leading to a soft lockup. Note how nid_of_current will never be equal to nid in that while loop because nid_of_current is not set in sgx_numa_mask.  Also worth mentioning is that it&#39;s perfectly fine for the firmware not to setup an EPC section on a node. While setting up an EPC section on each node can enhance performance, it is not a requirement for functionality.  Rework the loop to start and end on *a* node that has SGX memory. This avoids the deadlock looking for the current SGX-lacking node to show up in the loop when it never will.(CVE-2024-49856)In the Linux kernel, the following vulnerability has been resolved:  ksmbd: fix user-after-free from session log off  There is racy issue between smb2 session log off and smb2 session setup. It will cause user-after-free from session log off. This add session_lock when setting SMB2_SESSION_EXPIRED and referece count to session struct not to free session while it is being used.(CVE-2024-50086)In the Linux kernel, the following vulnerability has been resolved:  media: v4l2-tpg: prevent the risk of a division by zero  As reported by Coverity, the logic at tpg_precalculate_line() blindly rescales the buffer even when scaled_witdh is equal to zero. If this ever happens, this will cause a division by zero.  Instead, add a WARN_ON_ONCE() to trigger such cases and return without doing any precalculation.(CVE-2024-50287)In the Linux kernel, the following vulnerability has been resolved:  ALSA: usb-audio: Fix out of bounds reads when finding clock sources  The current USB-audio driver code doesn&#39;t check bLength of each descriptor at traversing for clock descriptors.  That is, when a device provides a bogus descriptor with a shorter bLength, the driver might hit out-of-bounds reads.  For addressing it, this patch adds sanity checks to the validator functions for the clock descriptor traversal.  When the descriptor length is shorter than expected, it&#39;s skipped in the loop.  For the clock source and clock multiplier descriptors, we can just check bLength against the sizeof() of each descriptor type. OTOH, the clock selector descriptor of UAC2 and UAC3 has an array of bNrInPins elements and two more fields at its tail, hence those have to be checked in addition to the sizeof() check.(CVE-2024-53150)In the Linux kernel, the following vulnerability has been resolved:  ocfs2: free inode when ocfs2_get_init_inode() fails  syzbot is reporting busy inodes after unmount, for commit 9c89fe0af826 (&#34;ocfs2: Handle error from dquot_initialize()&#34;) forgot to call iput() when new_inode() succeeded and dquot_initialize() failed.(CVE-2024-56630)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="bpftool" release="244.0.0.143.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-244.0.0.143.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="244.0.0.143.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-244.0.0.143.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="244.0.0.143.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-244.0.0.143.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="244.0.0.143.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-244.0.0.143.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="244.0.0.143.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-244.0.0.143.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="244.0.0.143.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-244.0.0.143.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="244.0.0.143.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-244.0.0.143.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="244.0.0.143.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-244.0.0.143.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="244.0.0.143.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-244.0.0.143.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="244.0.0.143.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-244.0.0.143.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="244.0.0.143.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-244.0.0.143.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="244.0.0.143.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-244.0.0.143.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="244.0.0.143.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-244.0.0.143.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="244.0.0.143.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-244.0.0.143.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="244.0.0.143.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-244.0.0.143.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="244.0.0.143.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-244.0.0.143.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="244.0.0.143.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-244.0.0.143.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="244.0.0.143.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-244.0.0.143.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="244.0.0.143.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-244.0.0.143.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="244.0.0.143.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-244.0.0.143.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="244.0.0.143.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-244.0.0.143.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="244.0.0.143.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-244.0.0.143.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="244.0.0.143.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-244.0.0.143.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="244.0.0.143.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-244.0.0.143.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="244.0.0.143.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-244.0.0.143.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="244.0.0.143.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-244.0.0.143.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="244.0.0.143.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-244.0.0.143.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="244.0.0.143.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-244.0.0.143.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="244.0.0.143.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-244.0.0.143.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="244.0.0.143.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-244.0.0.143.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1020</id>
          <title>An update for sox is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-01-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2019-13590" id="CVE-2019-13590" title="CVE-2019-13590" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2019-8354" id="CVE-2019-8354" title="CVE-2019-8354" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2019-8355" id="CVE-2019-8355" title="CVE-2019-8355" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2019-8356" id="CVE-2019-8356" title="CVE-2019-8356" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2019-8357" id="CVE-2019-8357" title="CVE-2019-8357" type="cve"></reference>
          </references>
          <description>An issue was discovered in libsox.a in SoX 14.4.2. In sox-fmt.h (startread function), there is an integer overflow on the result of integer addition (wraparound to 0) fed into the lsx_calloc macro that wraps malloc. When a NULL pointer is returned, it is used without a prior check that it is a valid pointer, leading to a NULL pointer dereference on lsx_readbuf in formats_i.c.(CVE-2019-13590)An issue was discovered in SoX 14.4.2. lsx_make_lpf in effect_i_dsp.c has an integer overflow on the result of multiplication fed into malloc. When the buffer is allocated, it is smaller than expected, leading to a heap-based buffer overflow.(CVE-2019-8354)An issue was discovered in SoX 14.4.2. In xmalloc.h, there is an integer overflow on the result of multiplication fed into the lsx_valloc macro that wraps malloc. When the buffer is allocated, it is smaller than expected, leading to a heap-based buffer overflow in channels_start in remix.c.(CVE-2019-8355)An issue was discovered in SoX 14.4.2. One of the arguments to bitrv2 in fft4g.c is not guarded, such that it can lead to write access outside of the statically declared array, aka a stack-based buffer overflow.(CVE-2019-8356)An issue was discovered in SoX 14.4.2. lsx_make_lpf in effect_i_dsp.c allows a NULL pointer dereference.(CVE-2019-8357)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="sox" release="31.oe2203sp4" version="14.4.2.0">
                         <filename>sox-14.4.2.0-31.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="sox-debuginfo" release="31.oe2203sp4" version="14.4.2.0">
                         <filename>sox-debuginfo-14.4.2.0-31.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="sox-debugsource" release="31.oe2203sp4" version="14.4.2.0">
                         <filename>sox-debugsource-14.4.2.0-31.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="sox-devel" release="31.oe2203sp4" version="14.4.2.0">
                         <filename>sox-devel-14.4.2.0-31.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="sox-help" release="31.oe2203sp4" version="14.4.2.0">
                         <filename>sox-help-14.4.2.0-31.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sox" release="31.oe2203sp4" version="14.4.2.0">
                         <filename>sox-14.4.2.0-31.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sox-debuginfo" release="31.oe2203sp4" version="14.4.2.0">
                         <filename>sox-debuginfo-14.4.2.0-31.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sox-debugsource" release="31.oe2203sp4" version="14.4.2.0">
                         <filename>sox-debugsource-14.4.2.0-31.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sox-devel" release="31.oe2203sp4" version="14.4.2.0">
                         <filename>sox-devel-14.4.2.0-31.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1022</id>
          <title>An update for curl is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2025-01-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-11053" id="CVE-2024-11053" title="CVE-2024-11053" type="cve"></reference>
          </references>
          <description>A vulnerability has been found in cURL (Network Utility Software) and classified as problematic. Affected by this vulnerability is an unknown code block of the component netrc File Handler. There is no information about possible countermeasures known. It may be suggested to replace the affected object with an alternative product.(CVE-2024-11053)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="curl" release="36.oe2203sp4" version="7.79.1">
                         <filename>curl-7.79.1-36.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="curl-debuginfo" release="36.oe2203sp4" version="7.79.1">
                         <filename>curl-debuginfo-7.79.1-36.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="curl-debugsource" release="36.oe2203sp4" version="7.79.1">
                         <filename>curl-debugsource-7.79.1-36.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libcurl" release="36.oe2203sp4" version="7.79.1">
                         <filename>libcurl-7.79.1-36.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libcurl-devel" release="36.oe2203sp4" version="7.79.1">
                         <filename>libcurl-devel-7.79.1-36.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="curl-help" release="36.oe2203sp4" version="7.79.1">
                         <filename>curl-help-7.79.1-36.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="curl" release="36.oe2203sp4" version="7.79.1">
                         <filename>curl-7.79.1-36.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="curl-debuginfo" release="36.oe2203sp4" version="7.79.1">
                         <filename>curl-debuginfo-7.79.1-36.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="curl-debugsource" release="36.oe2203sp4" version="7.79.1">
                         <filename>curl-debugsource-7.79.1-36.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libcurl" release="36.oe2203sp4" version="7.79.1">
                         <filename>libcurl-7.79.1-36.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libcurl-devel" release="36.oe2203sp4" version="7.79.1">
                         <filename>libcurl-devel-7.79.1-36.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1027</id>
          <title>An update for python3 is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2025-01-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-11168" id="CVE-2024-11168" title="CVE-2024-11168" type="cve"></reference>
          </references>
          <description>The urllib.parse.urlsplit() and urlparse() functions improperly validated bracketed hosts (`[]`), allowing hosts that weren&#39;t IPv6 or IPvFuture. This behavior was not conformant to RFC 3986 and potentially enabled SSRF if a URL is processed by more than one URL parser.(CVE-2024-11168)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="python3" release="40.oe2203sp4" version="3.9.9">
                         <filename>python3-3.9.9-40.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-debug" release="40.oe2203sp4" version="3.9.9">
                         <filename>python3-debug-3.9.9-40.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-debuginfo" release="40.oe2203sp4" version="3.9.9">
                         <filename>python3-debuginfo-3.9.9-40.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-debugsource" release="40.oe2203sp4" version="3.9.9">
                         <filename>python3-debugsource-3.9.9-40.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-devel" release="40.oe2203sp4" version="3.9.9">
                         <filename>python3-devel-3.9.9-40.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-unversioned-command" release="40.oe2203sp4" version="3.9.9">
                         <filename>python3-unversioned-command-3.9.9-40.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-help" release="40.oe2203sp4" version="3.9.9">
                         <filename>python3-help-3.9.9-40.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3" release="40.oe2203sp4" version="3.9.9">
                         <filename>python3-3.9.9-40.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-debug" release="40.oe2203sp4" version="3.9.9">
                         <filename>python3-debug-3.9.9-40.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-debuginfo" release="40.oe2203sp4" version="3.9.9">
                         <filename>python3-debuginfo-3.9.9-40.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-debugsource" release="40.oe2203sp4" version="3.9.9">
                         <filename>python3-debugsource-3.9.9-40.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-devel" release="40.oe2203sp4" version="3.9.9">
                         <filename>python3-devel-3.9.9-40.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-unversioned-command" release="40.oe2203sp4" version="3.9.9">
                         <filename>python3-unversioned-command-3.9.9-40.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1031</id>
          <title>An update for openjpeg2 is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-01-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56826" id="CVE-2024-56826" title="CVE-2024-56826" type="cve"></reference>
          </references>
          <description>This bug is triggered when we use opj_decompress with the -r option and its argument set to 2. Version v2.5.2 also has this vulnerability.  Reproducible: Always  Steps to Reproduce: see https://github.com/uclouvain/openjpeg/issues/1563  References:  https://github.com/uclouvain/openjpeg/issues/1563 https://github.com/uclouvain/openjpeg/commit/e492644fbded4c820ca55b5e50e598d346e850e8 https://bugzilla.redhat.com/show_bug.cgi?id=2333954(CVE-2024-56826)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="openjpeg2" release="5.oe2203sp4" version="2.5.0">
                         <filename>openjpeg2-2.5.0-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openjpeg2-debuginfo" release="5.oe2203sp4" version="2.5.0">
                         <filename>openjpeg2-debuginfo-2.5.0-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openjpeg2-debugsource" release="5.oe2203sp4" version="2.5.0">
                         <filename>openjpeg2-debugsource-2.5.0-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openjpeg2-devel" release="5.oe2203sp4" version="2.5.0">
                         <filename>openjpeg2-devel-2.5.0-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openjpeg2-tools" release="5.oe2203sp4" version="2.5.0">
                         <filename>openjpeg2-tools-2.5.0-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="openjpeg2-help" release="5.oe2203sp4" version="2.5.0">
                         <filename>openjpeg2-help-2.5.0-5.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openjpeg2" release="5.oe2203sp4" version="2.5.0">
                         <filename>openjpeg2-2.5.0-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openjpeg2-debuginfo" release="5.oe2203sp4" version="2.5.0">
                         <filename>openjpeg2-debuginfo-2.5.0-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openjpeg2-debugsource" release="5.oe2203sp4" version="2.5.0">
                         <filename>openjpeg2-debugsource-2.5.0-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openjpeg2-devel" release="5.oe2203sp4" version="2.5.0">
                         <filename>openjpeg2-devel-2.5.0-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openjpeg2-tools" release="5.oe2203sp4" version="2.5.0">
                         <filename>openjpeg2-tools-2.5.0-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1037</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-01-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49034" id="CVE-2022-49034" title="CVE-2022-49034" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47730" id="CVE-2024-47730" title="CVE-2024-47730" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49907" id="CVE-2024-49907" title="CVE-2024-49907" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50001" id="CVE-2024-50001" title="CVE-2024-50001" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50188" id="CVE-2024-50188" title="CVE-2024-50188" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50233" id="CVE-2024-50233" title="CVE-2024-50233" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50264" id="CVE-2024-50264" title="CVE-2024-50264" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53146" id="CVE-2024-53146" title="CVE-2024-53146" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53147" id="CVE-2024-53147" title="CVE-2024-53147" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53155" id="CVE-2024-53155" title="CVE-2024-53155" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53158" id="CVE-2024-53158" title="CVE-2024-53158" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53161" id="CVE-2024-53161" title="CVE-2024-53161" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53165" id="CVE-2024-53165" title="CVE-2024-53165" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53173" id="CVE-2024-53173" title="CVE-2024-53173" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53185" id="CVE-2024-53185" title="CVE-2024-53185" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53187" id="CVE-2024-53187" title="CVE-2024-53187" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53194" id="CVE-2024-53194" title="CVE-2024-53194" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53197" id="CVE-2024-53197" title="CVE-2024-53197" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53217" id="CVE-2024-53217" title="CVE-2024-53217" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53218" id="CVE-2024-53218" title="CVE-2024-53218" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53219" id="CVE-2024-53219" title="CVE-2024-53219" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53221" id="CVE-2024-53221" title="CVE-2024-53221" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53224" id="CVE-2024-53224" title="CVE-2024-53224" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53227" id="CVE-2024-53227" title="CVE-2024-53227" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56538" id="CVE-2024-56538" title="CVE-2024-56538" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56548" id="CVE-2024-56548" title="CVE-2024-56548" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56562" id="CVE-2024-56562" title="CVE-2024-56562" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56569" id="CVE-2024-56569" title="CVE-2024-56569" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56570" id="CVE-2024-56570" title="CVE-2024-56570" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56572" id="CVE-2024-56572" title="CVE-2024-56572" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56581" id="CVE-2024-56581" title="CVE-2024-56581" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56583" id="CVE-2024-56583" title="CVE-2024-56583" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56584" id="CVE-2024-56584" title="CVE-2024-56584" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56586" id="CVE-2024-56586" title="CVE-2024-56586" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56594" id="CVE-2024-56594" title="CVE-2024-56594" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56596" id="CVE-2024-56596" title="CVE-2024-56596" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56598" id="CVE-2024-56598" title="CVE-2024-56598" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56604" id="CVE-2024-56604" title="CVE-2024-56604" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56605" id="CVE-2024-56605" title="CVE-2024-56605" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56608" id="CVE-2024-56608" title="CVE-2024-56608" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56615" id="CVE-2024-56615" title="CVE-2024-56615" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56619" id="CVE-2024-56619" title="CVE-2024-56619" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56627" id="CVE-2024-56627" title="CVE-2024-56627" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56629" id="CVE-2024-56629" title="CVE-2024-56629" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56672" id="CVE-2024-56672" title="CVE-2024-56672" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56681" id="CVE-2024-56681" title="CVE-2024-56681" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56686" id="CVE-2024-56686" title="CVE-2024-56686" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56691" id="CVE-2024-56691" title="CVE-2024-56691" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56692" id="CVE-2024-56692" title="CVE-2024-56692" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56700" id="CVE-2024-56700" title="CVE-2024-56700" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56709" id="CVE-2024-56709" title="CVE-2024-56709" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56739" id="CVE-2024-56739" title="CVE-2024-56739" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56741" id="CVE-2024-56741" title="CVE-2024-56741" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56747" id="CVE-2024-56747" title="CVE-2024-56747" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56748" id="CVE-2024-56748" title="CVE-2024-56748" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56756" id="CVE-2024-56756" title="CVE-2024-56756" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56763" id="CVE-2024-56763" title="CVE-2024-56763" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:  sh: cpuinfo: Fix a warning for CONFIG_CPUMASK_OFFSTACK  When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS are selected, cpu_max_bits_warn() generates a runtime warning similar as below when showing /proc/cpuinfo. Fix this by using nr_cpu_ids (the runtime limit) instead of NR_CPUS to iterate CPUs.  [    3.052463] ------------[ cut here ]------------ [    3.059679] WARNING: CPU: 3 PID: 1 at include/linux/cpumask.h:108 show_cpuinfo+0x5e8/0x5f0 [    3.070072] Modules linked in: efivarfs autofs4 [    3.076257] CPU: 0 PID: 1 Comm: systemd Not tainted 5.19-rc5+ #1052 [    3.099465] Stack : 9000000100157b08 9000000000f18530 9000000000cf846c 9000000100154000 [    3.109127]         9000000100157a50 0000000000000000 9000000100157a58 9000000000ef7430 [    3.118774]         90000001001578e8 0000000000000040 0000000000000020 ffffffffffffffff [    3.128412]         0000000000aaaaaa 1ab25f00eec96a37 900000010021de80 900000000101c890 [    3.138056]         0000000000000000 0000000000000000 0000000000000000 0000000000aaaaaa [    3.147711]         ffff8000339dc220 0000000000000001 0000000006ab4000 0000000000000000 [    3.157364]         900000000101c998 0000000000000004 9000000000ef7430 0000000000000000 [    3.167012]         0000000000000009 000000000000006c 0000000000000000 0000000000000000 [    3.176641]         9000000000d3de08 9000000001639390 90000000002086d8 00007ffff0080286 [    3.186260]         00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c [    3.195868]         ... [    3.199917] Call Trace: [    3.203941] [&lt;90000000002086d8&gt;] show_stack+0x38/0x14c [    3.210666] [&lt;9000000000cf846c&gt;] dump_stack_lvl+0x60/0x88 [    3.217625] [&lt;900000000023d268&gt;] __warn+0xd0/0x100 [    3.223958] [&lt;9000000000cf3c90&gt;] warn_slowpath_fmt+0x7c/0xcc [    3.231150] [&lt;9000000000210220&gt;] show_cpuinfo+0x5e8/0x5f0 [    3.238080] [&lt;90000000004f578c&gt;] seq_read_iter+0x354/0x4b4 [    3.245098] [&lt;90000000004c2e90&gt;] new_sync_read+0x17c/0x1c4 [    3.252114] [&lt;90000000004c5174&gt;] vfs_read+0x138/0x1d0 [    3.258694] [&lt;90000000004c55f8&gt;] ksys_read+0x70/0x100 [    3.265265] [&lt;9000000000cfde9c&gt;] do_syscall+0x7c/0x94 [    3.271820] [&lt;9000000000202fe4&gt;] handle_syscall+0xc4/0x160 [    3.281824] ---[ end trace 8b484262b4b8c24c ]---(CVE-2022-49034)In the Linux kernel, the following vulnerability has been resolved:  crypto: hisilicon/qm - inject error before stopping queue  The master ooo cannot be completely closed when the accelerator core reports memory error. Therefore, the driver needs to inject the qm error to close the master ooo. Currently, the qm error is injected after stopping queue, memory may be released immediately after stopping queue, causing the device to access the released memory. Therefore, error is injected to close master ooo before stopping queue to ensure that the device does not access the released memory.(CVE-2024-47730)In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Check null pointers before using dc-&gt;clk_mgr  [WHY &amp; HOW] dc-&gt;clk_mgr is null checked previously in the same function, indicating it might be null.  Passing &#34;dc&#34; to &#34;dc-&gt;hwss.apply_idle_power_optimizations&#34;, which dereferences null &#34;dc-&gt;clk_mgr&#34;. (The function pointer resolves to &#34;dcn35_apply_idle_power_optimizations&#34;.)  This fixes 1 FORWARD_NULL issue reported by Coverity.(CVE-2024-49907)In the Linux kernel, the following vulnerability has been resolved:  net/mlx5: Fix error path in multi-packet WQE transmit  Remove the erroneous unmap in case no DMA mapping was established  The multi-packet WQE transmit code attempts to obtain a DMA mapping for the skb. This could fail, e.g. under memory pressure, when the IOMMU driver just can&#39;t allocate more memory for page tables. While the code tries to handle this in the path below the err_unmap label it erroneously unmaps one entry from the sq&#39;s FIFO list of active mappings. Since the current map attempt failed this unmap is removing some random DMA mapping that might still be required. If the PCI function now presents that IOVA, the IOMMU may assumes a rogue DMA access and e.g. on s390 puts the PCI function in error state.  The erroneous behavior was seen in a stress-test environment that created memory pressure.(CVE-2024-50001)In the Linux kernel, the following vulnerability has been resolved:  net: phy: dp83869: fix memory corruption when enabling fiber  When configuring the fiber port, the DP83869 PHY driver incorrectly calls linkmode_set_bit() with a bit mask (1 &lt;&lt; 10) rather than a bit number (10). This corrupts some other memory location -- in case of arm64 the priv pointer in the same structure.  Since the advertising flags are updated from supported at the end of the function the incorrect line isn&#39;t needed at all and can be removed.(CVE-2024-50188)In the Linux kernel, the following vulnerability has been resolved:  staging: iio: frequency: ad9832: fix division by zero in ad9832_calc_freqreg()  In the ad9832_write_frequency() function, clk_get_rate() might return 0. This can lead to a division by zero when calling ad9832_calc_freqreg(). The check if (fout &gt; (clk_get_rate(st-&gt;mclk) / 2)) does not protect against the case when fout is 0. The ad9832_write_frequency() function is called from ad9832_write(), and fout is derived from a text buffer, which can contain any value.(CVE-2024-50233)In the Linux kernel, the following vulnerability has been resolved:  vsock/virtio: Initialization of the dangling pointer occurring in vsk-&gt;trans  During loopback communication, a dangling pointer can be created in vsk-&gt;trans, potentially leading to a Use-After-Free condition.  This issue is resolved by initializing vsk-&gt;trans to NULL.(CVE-2024-50264)In the Linux kernel, the following vulnerability has been resolved:  NFSD: Prevent a potential integer overflow  If the tag length is &gt;= U32_MAX - 3 then the &#34;length + 4&#34; addition can result in an integer overflow. Address this by splitting the decoding into several steps so that decode_cb_compound4res() does not have to perform arithmetic on the unsafe length value.(CVE-2024-53146)In the Linux kernel, the following vulnerability has been resolved:  exfat: fix out-of-bounds access of directory entries  In the case of the directory size is greater than or equal to the cluster size, if start_clu becomes an EOF cluster(an invalid cluster) due to file system corruption, then the directory entry where ei-&gt;hint_femp.eidx hint is outside the directory, resulting in an out-of-bounds access, which may cause further file system corruption.  This commit adds a check for start_clu, if it is an invalid cluster, the file or directory will be treated as empty.(CVE-2024-53147)In the Linux kernel, the following vulnerability has been resolved:  ocfs2: fix uninitialized value in ocfs2_file_read_iter()  Syzbot has reported the following KMSAN splat:  BUG: KMSAN: uninit-value in ocfs2_file_read_iter+0x9a4/0xf80  ocfs2_file_read_iter+0x9a4/0xf80  __io_read+0x8d4/0x20f0  io_read+0x3e/0xf0  io_issue_sqe+0x42b/0x22c0  io_wq_submit_work+0xaf9/0xdc0  io_worker_handle_work+0xd13/0x2110  io_wq_worker+0x447/0x1410  ret_from_fork+0x6f/0x90  ret_from_fork_asm+0x1a/0x30  Uninit was created at:  __alloc_pages_noprof+0x9a7/0xe00  alloc_pages_mpol_noprof+0x299/0x990  alloc_pages_noprof+0x1bf/0x1e0  allocate_slab+0x33a/0x1250  ___slab_alloc+0x12ef/0x35e0  kmem_cache_alloc_bulk_noprof+0x486/0x1330  __io_alloc_req_refill+0x84/0x560  io_submit_sqes+0x172f/0x2f30  __se_sys_io_uring_enter+0x406/0x41c0  __x64_sys_io_uring_enter+0x11f/0x1a0  x64_sys_call+0x2b54/0x3ba0  do_syscall_64+0xcd/0x1e0  entry_SYSCALL_64_after_hwframe+0x77/0x7f  Since an instance of &#39;struct kiocb&#39; may be passed from the block layer with &#39;private&#39; field uninitialized, introduce &#39;ocfs2_iocb_init_rw_locked()&#39; and use it from where &#39;ocfs2_dio_end_io()&#39; might take care, i.e. in &#39;ocfs2_file_read_iter()&#39; and &#39;ocfs2_file_write_iter()&#39;.(CVE-2024-53155)In the Linux kernel, the following vulnerability has been resolved:  soc: qcom: geni-se: fix array underflow in geni_se_clk_tbl_get()  This loop is supposed to break if the frequency returned from clk_round_rate() is the same as on the previous iteration.  However, that check doesn&#39;t make sense on the first iteration through the loop. It leads to reading before the start of these-&gt;clk_perf_tbl[] array.(CVE-2024-53158)In the Linux kernel, the following vulnerability has been resolved:  EDAC/bluefield: Fix potential integer overflow  The 64-bit argument for the &#34;get DIMM info&#34; SMC call consists of mem_ctrl_idx left-shifted 16 bits and OR-ed with DIMM index.  With mem_ctrl_idx defined as 32-bits wide the left-shift operation truncates the upper 16 bits of information during the calculation of the SMC argument.  The mem_ctrl_idx stack variable must be defined as 64-bits wide to prevent any potential integer overflow, i.e. loss of data from upper 16 bits.(CVE-2024-53161)In the Linux kernel, the following vulnerability has been resolved:  sh: intc: Fix use-after-free bug in register_intc_controller()  In the error handling for this function, d is freed without ever removing it from intc_list which would lead to a use after free. To fix this, let&#39;s only add it to the list after everything has succeeded.(CVE-2024-53165)In the Linux kernel, the following vulnerability has been resolved:  NFSv4.0: Fix a use-after-free problem in the asynchronous open()  Yang Erkun reports that when two threads are opening files at the same time, and are forced to abort before a reply is seen, then the call to nfs_release_seqid() in nfs4_opendata_free() can result in a use-after-free of the pointer to the defunct rpc task of the other thread. The fix is to ensure that if the RPC call is aborted before the call to nfs_wait_on_sequence() is complete, then we must call nfs_release_seqid() in nfs4_open_release() before the rpc_task is freed.(CVE-2024-53173)In the Linux kernel, the following vulnerability has been resolved:  smb: client: fix NULL ptr deref in crypto_aead_setkey()  Neither SMB3.0 or SMB3.02 supports encryption negotiate context, so when SMB2_GLOBAL_CAP_ENCRYPTION flag is set in the negotiate response, the client uses AES-128-CCM as the default cipher.  See MS-SMB2 3.3.5.4.  Commit b0abcd65ec54 (&#34;smb: client: fix UAF in async decryption&#34;) added a @server-&gt;cipher_type check to conditionally call smb3_crypto_aead_allocate(), but that check would always be false as @server-&gt;cipher_type is unset for SMB3.02.  Fix the following KASAN splat by setting @server-&gt;cipher_type for SMB3.02 as well.  mount.cifs //srv/share /mnt -o vers=3.02,seal,...  BUG: KASAN: null-ptr-deref in crypto_aead_setkey+0x2c/0x130 Read of size 8 at addr 0000000000000020 by task mount.cifs/1095 CPU: 1 UID: 0 PID: 1095 Comm: mount.cifs Not tainted 6.12.0 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc41 04/01/2014 Call Trace:  &lt;TASK&gt;  dump_stack_lvl+0x5d/0x80  ? crypto_aead_setkey+0x2c/0x130  kasan_report+0xda/0x110  ? crypto_aead_setkey+0x2c/0x130  crypto_aead_setkey+0x2c/0x130  crypt_message+0x258/0xec0 [cifs]  ? __asan_memset+0x23/0x50  ? __pfx_crypt_message+0x10/0x10 [cifs]  ? mark_lock+0xb0/0x6a0  ? hlock_class+0x32/0xb0  ? mark_lock+0xb0/0x6a0  smb3_init_transform_rq+0x352/0x3f0 [cifs]  ? lock_acquire.part.0+0xf4/0x2a0  smb_send_rqst+0x144/0x230 [cifs]  ? __pfx_smb_send_rqst+0x10/0x10 [cifs]  ? hlock_class+0x32/0xb0  ? smb2_setup_request+0x225/0x3a0 [cifs]  ? __pfx_cifs_compound_last_callback+0x10/0x10 [cifs]  compound_send_recv+0x59b/0x1140 [cifs]  ? __pfx_compound_send_recv+0x10/0x10 [cifs]  ? __create_object+0x5e/0x90  ? hlock_class+0x32/0xb0  ? do_raw_spin_unlock+0x9a/0xf0  cifs_send_recv+0x23/0x30 [cifs]  SMB2_tcon+0x3ec/0xb30 [cifs]  ? __pfx_SMB2_tcon+0x10/0x10 [cifs]  ? lock_acquire.part.0+0xf4/0x2a0  ? __pfx_lock_release+0x10/0x10  ? do_raw_spin_trylock+0xc6/0x120  ? lock_acquire+0x3f/0x90  ? _get_xid+0x16/0xd0 [cifs]  ? __pfx_SMB2_tcon+0x10/0x10 [cifs]  ? cifs_get_smb_ses+0xcdd/0x10a0 [cifs]  cifs_get_smb_ses+0xcdd/0x10a0 [cifs]  ? __pfx_cifs_get_smb_ses+0x10/0x10 [cifs]  ? cifs_get_tcp_session+0xaa0/0xca0 [cifs]  cifs_mount_get_session+0x8a/0x210 [cifs]  dfs_mount_share+0x1b0/0x11d0 [cifs]  ? __pfx___lock_acquire+0x10/0x10  ? __pfx_dfs_mount_share+0x10/0x10 [cifs]  ? lock_acquire.part.0+0xf4/0x2a0  ? find_held_lock+0x8a/0xa0  ? hlock_class+0x32/0xb0  ? lock_release+0x203/0x5d0  cifs_mount+0xb3/0x3d0 [cifs]  ? do_raw_spin_trylock+0xc6/0x120  ? __pfx_cifs_mount+0x10/0x10 [cifs]  ? lock_acquire+0x3f/0x90  ? find_nls+0x16/0xa0  ? smb3_update_mnt_flags+0x372/0x3b0 [cifs]  cifs_smb3_do_mount+0x1e2/0xc80 [cifs]  ? __pfx_vfs_parse_fs_string+0x10/0x10  ? __pfx_cifs_smb3_do_mount+0x10/0x10 [cifs]  smb3_get_tree+0x1bf/0x330 [cifs]  vfs_get_tree+0x4a/0x160  path_mount+0x3c1/0xfb0  ? kasan_quarantine_put+0xc7/0x1d0  ? __pfx_path_mount+0x10/0x10  ? kmem_cache_free+0x118/0x3e0  ? user_path_at+0x74/0xa0  __x64_sys_mount+0x1a6/0x1e0  ? __pfx___x64_sys_mount+0x10/0x10  ? mark_held_locks+0x1a/0x90  do_syscall_64+0xbb/0x1d0  entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-53185)In the Linux kernel, the following vulnerability has been resolved:  io_uring: check for overflows in io_pin_pages  WARNING: CPU: 0 PID: 5834 at io_uring/memmap.c:144 io_pin_pages+0x149/0x180 io_uring/memmap.c:144 CPU: 0 UID: 0 PID: 5834 Comm: syz-executor825 Not tainted 6.12.0-next-20241118-syzkaller #0 Call Trace:  &lt;TASK&gt;  __io_uaddr_map+0xfb/0x2d0 io_uring/memmap.c:183  io_rings_map io_uring/io_uring.c:2611 [inline]  io_allocate_scq_urings+0x1c0/0x650 io_uring/io_uring.c:3470  io_uring_create+0x5b5/0xc00 io_uring/io_uring.c:3692  io_uring_setup io_uring/io_uring.c:3781 [inline]  ...  &lt;/TASK&gt;  io_pin_pages()&#39;s uaddr parameter came directly from the user and can be garbage. Don&#39;t just add size to it as it can overflow.(CVE-2024-53187)In the Linux kernel, the following vulnerability has been resolved:  PCI: Fix use-after-free of slot-&gt;bus on hot remove  Dennis reports a boot crash on recent Lenovo laptops with a USB4 dock.  Since commit 0fc70886569c (&#34;thunderbolt: Reset USB4 v2 host router&#34;) and commit 59a54c5f3dbd (&#34;thunderbolt: Reset topology created by the boot firmware&#34;), USB4 v2 and v1 Host Routers are reset on probe of the thunderbolt driver.  The reset clears the Presence Detect State and Data Link Layer Link Active bits at the USB4 Host Router&#39;s Root Port and thus causes hot removal of the dock.  The crash occurs when pciehp is unbound from one of the dock&#39;s Downstream Ports:  pciehp creates a pci_slot on bind and destroys it on unbind.  The pci_slot contains a pointer to the pci_bus below the Downstream Port, but a reference on that pci_bus is never acquired.  The pci_bus is destroyed before the pci_slot, so a use-after-free ensues when pci_slot_release() accesses slot-&gt;bus.  In principle this should not happen because pci_stop_bus_device() unbinds pciehp (and therefore destroys the pci_slot) before the pci_bus is destroyed by pci_remove_bus_device().  However the stacktrace provided by Dennis shows that pciehp is unbound from pci_remove_bus_device() instead of pci_stop_bus_device().  To understand the significance of this, one needs to know that the PCI core uses a two step process to remove a portion of the hierarchy:  It first unbinds all drivers in the sub-hierarchy in pci_stop_bus_device() and then actually removes the devices in pci_remove_bus_device().  There is no precaution to prevent driver binding in-between pci_stop_bus_device() and pci_remove_bus_device().  In Dennis&#39; case, it seems removal of the hierarchy by pciehp races with driver binding by pci_bus_add_devices().  pciehp is bound to the Downstream Port after pci_stop_bus_device() has run, so it is unbound by pci_remove_bus_device() instead of pci_stop_bus_device().  Because the pci_bus has already been destroyed at that point, accesses to it result in a use-after-free.  One might conclude that driver binding needs to be prevented after pci_stop_bus_device() has run.  However it seems risky that pci_slot points to pci_bus without holding a reference.  Solely relying on correct ordering of driver unbind versus pci_bus destruction is certainly not defensive programming.  If pci_slot has a need to access data in pci_bus, it ought to acquire a reference.  Amend pci_create_slot() accordingly.  Dennis reports that the crash is not reproducible with this change.  Abridged stacktrace:    pcieport 0000:00:07.0: PME: Signaling with IRQ 156   pcieport 0000:00:07.0: pciehp: Slot #12 AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ Interlock- NoCompl+ IbPresDis- LLActRep+   pci_bus 0000:20: dev 00, created physical slot 12   pcieport 0000:00:07.0: pciehp: Slot(12): Card not present   ...   pcieport 0000:21:02.0: pciehp: pcie_disable_notification: SLOTCTRL d8 write cmd 0   Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI   CPU: 13 UID: 0 PID: 134 Comm: irq/156-pciehp Not tainted 6.11.0-devel+ #1   RIP: 0010:dev_driver_string+0x12/0x40   pci_destroy_slot   pciehp_remove   pcie_port_remove_service   device_release_driver_internal   bus_remove_device   device_del   device_unregister   remove_iter   device_for_each_child   pcie_portdrv_remove   pci_device_remove   device_release_driver_internal   bus_remove_device   device_del   pci_remove_bus_device (recursive invocation)   pci_remove_bus_device   pciehp_unconfigure_device   pciehp_disable_slot   pciehp_handle_presence_or_link_change   pciehp_ist(CVE-2024-53194)In the Linux kernel, the following vulnerability has been resolved:  ALSA: usb-audio: Fix potential out-of-bound accesses for Extigy and Mbox devices  A bogus device can provide a bNumConfigurations value that exceeds the initial value used in usb_get_configuration for allocating dev-&gt;config.  This can lead to out-of-bounds accesses later, e.g. in usb_destroy_configuration.(CVE-2024-53197)In the Linux kernel, the following vulnerability has been resolved:  NFSD: Prevent NULL dereference in nfsd4_process_cb_update()  @ses is initialized to NULL. If __nfsd4_find_backchannel() finds no available backchannel session, setup_callback_client() will try to dereference @ses and segfault.(CVE-2024-53217)In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix race in concurrent f2fs_stop_gc_thread  In my test case, concurrent calls to f2fs shutdown report the following stack trace:   Oops: general protection fault, probably for non-canonical address 0xc6cfff63bb5513fc: 0000 [#1] PREEMPT SMP PTI  CPU: 0 UID: 0 PID: 678 Comm: f2fs_rep_shutdo Not tainted 6.12.0-rc5-next-20241029-g6fb2fa9805c5-dirty #85  Call Trace:   &lt;TASK&gt;   ? show_regs+0x8b/0xa0   ? __die_body+0x26/0xa0   ? die_addr+0x54/0x90   ? exc_general_protection+0x24b/0x5c0   ? asm_exc_general_protection+0x26/0x30   ? kthread_stop+0x46/0x390   f2fs_stop_gc_thread+0x6c/0x110   f2fs_do_shutdown+0x309/0x3a0   f2fs_ioc_shutdown+0x150/0x1c0   __f2fs_ioctl+0xffd/0x2ac0   f2fs_ioctl+0x76/0xe0   vfs_ioctl+0x23/0x60   __x64_sys_ioctl+0xce/0xf0   x64_sys_call+0x2b1b/0x4540   do_syscall_64+0xa7/0x240   entry_SYSCALL_64_after_hwframe+0x76/0x7e  The root cause is a race condition in f2fs_stop_gc_thread() called from different f2fs shutdown paths:    [CPU0]                       [CPU1]   ----------------------       -----------------------   f2fs_stop_gc_thread          f2fs_stop_gc_thread                                  gc_th = sbi-&gt;gc_thread     gc_th = sbi-&gt;gc_thread     kfree(gc_th)     sbi-&gt;gc_thread = NULL                                  &lt; gc_th != NULL &gt;                                  kthread_stop(gc_th-&gt;f2fs_gc_task) //UAF  The commit c7f114d864ac (&#34;f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread()&#34;) attempted to fix this issue by using a read semaphore to prevent races between shutdown and remount threads, but it fails to prevent all race conditions.  Fix it by converting to write lock of s_umount in f2fs_do_shutdown().(CVE-2024-53218)In the Linux kernel, the following vulnerability has been resolved:  virtiofs: use pages instead of pointer for kernel direct IO  When trying to insert a 10MB kernel module kept in a virtio-fs with cache disabled, the following warning was reported:    ------------[ cut here ]------------   WARNING: CPU: 1 PID: 404 at mm/page_alloc.c:4551 ......   Modules linked in:   CPU: 1 PID: 404 Comm: insmod Not tainted 6.9.0-rc5+ #123   Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ......   RIP: 0010:__alloc_pages+0x2bf/0x380   ......   Call Trace:    &lt;TASK&gt;    ? __warn+0x8e/0x150    ? __alloc_pages+0x2bf/0x380    __kmalloc_large_node+0x86/0x160    __kmalloc+0x33c/0x480    virtio_fs_enqueue_req+0x240/0x6d0    virtio_fs_wake_pending_and_unlock+0x7f/0x190    queue_request_and_unlock+0x55/0x60    fuse_simple_request+0x152/0x2b0    fuse_direct_io+0x5d2/0x8c0    fuse_file_read_iter+0x121/0x160    __kernel_read+0x151/0x2d0    kernel_read+0x45/0x50    kernel_read_file+0x1a9/0x2a0    init_module_from_file+0x6a/0xe0    idempotent_init_module+0x175/0x230    __x64_sys_finit_module+0x5d/0xb0    x64_sys_call+0x1c3/0x9e0    do_syscall_64+0x3d/0xc0    entry_SYSCALL_64_after_hwframe+0x4b/0x53    ......    &lt;/TASK&gt;   ---[ end trace 0000000000000000 ]---  The warning is triggered as follows:  1) syscall finit_module() handles the module insertion and it invokes kernel_read_file() to read the content of the module first.  2) kernel_read_file() allocates a 10MB buffer by using vmalloc() and passes it to kernel_read(). kernel_read() constructs a kvec iter by using iov_iter_kvec() and passes it to fuse_file_read_iter().  3) virtio-fs disables the cache, so fuse_file_read_iter() invokes fuse_direct_io(). As for now, the maximal read size for kvec iter is only limited by fc-&gt;max_read. For virtio-fs, max_read is UINT_MAX, so fuse_direct_io() doesn&#39;t split the 10MB buffer. It saves the address and the size of the 10MB-sized buffer in out_args[0] of a fuse request and passes the fuse request to virtio_fs_wake_pending_and_unlock().  4) virtio_fs_wake_pending_and_unlock() uses virtio_fs_enqueue_req() to queue the request. Because virtiofs need DMA-able address, so virtio_fs_enqueue_req() uses kmalloc() to allocate a bounce buffer for all fuse args, copies these args into the bounce buffer and passed the physical address of the bounce buffer to virtiofsd. The total length of these fuse args for the passed fuse request is about 10MB, so copy_args_to_argbuf() invokes kmalloc() with a 10MB size parameter and it triggers the warning in __alloc_pages():   if (WARN_ON_ONCE_GFP(order &gt; MAX_PAGE_ORDER, gfp))   return NULL;  5) virtio_fs_enqueue_req() will retry the memory allocation in a kworker, but it won&#39;t help, because kmalloc() will always return NULL due to the abnormal size and finit_module() will hang forever.  A feasible solution is to limit the value of max_read for virtio-fs, so the length passed to kmalloc() will be limited. However it will affect the maximal read size for normal read. And for virtio-fs write initiated from kernel, it has the similar problem but now there is no way to limit fc-&gt;max_write in kernel.  So instead of limiting both the values of max_read and max_write in kernel, introducing use_pages_for_kvec_io in fuse_conn and setting it as true in virtiofs. When use_pages_for_kvec_io is enabled, fuse will use pages instead of pointer to pass the KVEC_IO data.  After switching to pages for KVEC_IO data, these pages will be used for DMA through virtio-fs. If these pages are backed by vmalloc(), {flush|invalidate}_kernel_vmap_range() are necessary to flush or invalidate the cache before the DMA operation. So add two new fields in fuse_args_pages to record the base address of vmalloc area and the condition indicating whether invalidation is needed. Perform the flush in fuse_get_user_pages() for write operations and the invalidation in fuse_release_user_pages() for read operations.  It may seem necessary to introduce another fie ---truncated---(CVE-2024-53219)In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix null-ptr-deref in f2fs_submit_page_bio()  There&#39;s issue as follows when concurrently installing the f2fs.ko module and mounting the f2fs file system: KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027] RIP: 0010:__bio_alloc+0x2fb/0x6c0 [f2fs] Call Trace:  &lt;TASK&gt;  f2fs_submit_page_bio+0x126/0x8b0 [f2fs]  __get_meta_page+0x1d4/0x920 [f2fs]  get_checkpoint_version.constprop.0+0x2b/0x3c0 [f2fs]  validate_checkpoint+0xac/0x290 [f2fs]  f2fs_get_valid_checkpoint+0x207/0x950 [f2fs]  f2fs_fill_super+0x1007/0x39b0 [f2fs]  mount_bdev+0x183/0x250  legacy_get_tree+0xf4/0x1e0  vfs_get_tree+0x88/0x340  do_new_mount+0x283/0x5e0  path_mount+0x2b2/0x15b0  __x64_sys_mount+0x1fe/0x270  do_syscall_64+0x5f/0x170  entry_SYSCALL_64_after_hwframe+0x76/0x7e  Above issue happens as the biset of the f2fs file system is not initialized before register &#34;f2fs_fs_type&#34;. To address above issue just register &#34;f2fs_fs_type&#34; at the last in init_f2fs_fs(). Ensure that all f2fs file system resources are initialized.(CVE-2024-53221)In the Linux kernel, the following vulnerability has been resolved:  RDMA/mlx5: Move events notifier registration to be after device registration  Move pkey change work initialization and cleanup from device resources stage to notifier stage, since this is the stage which handles this work events.  Fix a race between the device deregistration and pkey change work by moving MLX5_IB_STAGE_DEVICE_NOTIFIER to be after MLX5_IB_STAGE_IB_REG in order to ensure that the notifier is deregistered before the device during cleanup. Which ensures there are no works that are being executed after the device has already unregistered which can cause the panic below.  BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 630071 Comm: kworker/1:2 Kdump: loaded Tainted: G W OE --------- --- 5.14.0-162.6.1.el9_1.x86_64 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090008 02/27/2023 Workqueue: events pkey_change_handler [mlx5_ib] RIP: 0010:setup_qp+0x38/0x1f0 [mlx5_ib] Code: ee 41 54 45 31 e4 55 89 f5 53 48 89 fb 48 83 ec 20 8b 77 08 65 48 8b 04 25 28 00 00 00 48 89 44 24 18 48 8b 07 48 8d 4c 24 16 &lt;4c&gt; 8b 38 49 8b 87 80 0b 00 00 4c 89 ff 48 8b 80 08 05 00 00 8b 40 RSP: 0018:ffffbcc54068be20 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff954054494128 RCX: ffffbcc54068be36 RDX: ffff954004934000 RSI: 0000000000000001 RDI: ffff954054494128 RBP: 0000000000000023 R08: ffff954001be2c20 R09: 0000000000000001 R10: ffff954001be2c20 R11: ffff9540260133c0 R12: 0000000000000000 R13: 0000000000000023 R14: 0000000000000000 R15: ffff9540ffcb0905 FS: 0000000000000000(0000) GS:ffff9540ffc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010625c001 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: mlx5_ib_gsi_pkey_change+0x20/0x40 [mlx5_ib] process_one_work+0x1e8/0x3c0 worker_thread+0x50/0x3b0 ? rescuer_thread+0x380/0x380 kthread+0x149/0x170 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x22/0x30 Modules linked in: rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) mlx5_fwctl(OE) fwctl(OE) ib_uverbs(OE) mlx5_core(OE) mlxdevm(OE) ib_core(OE) mlx_compat(OE) psample mlxfw(OE) tls knem(OE) netconsole nfsv3 nfs_acl nfs lockd grace fscache netfs qrtr rfkill sunrpc intel_rapl_msr intel_rapl_common rapl hv_balloon hv_utils i2c_piix4 pcspkr joydev fuse ext4 mbcache jbd2 sr_mod sd_mod cdrom t10_pi sg ata_generic pci_hyperv pci_hyperv_intf hyperv_drm drm_shmem_helper drm_kms_helper hv_storvsc syscopyarea hv_netvsc sysfillrect sysimgblt hid_hyperv fb_sys_fops scsi_transport_fc hyperv_keyboard drm ata_piix crct10dif_pclmul crc32_pclmul crc32c_intel libata ghash_clmulni_intel hv_vmbus serio_raw [last unloaded: ib_core] CR2: 0000000000000000 ---[ end trace f6f8be4eae12f7bc ]---(CVE-2024-53224)In the Linux kernel, the following vulnerability has been resolved:  scsi: bfa: Fix use-after-free in bfad_im_module_exit()  BUG: KASAN: slab-use-after-free in __lock_acquire+0x2aca/0x3a20 Read of size 8 at addr ffff8881082d80c8 by task modprobe/25303  Call Trace:  &lt;TASK&gt;  dump_stack_lvl+0x95/0xe0  print_report+0xcb/0x620  kasan_report+0xbd/0xf0  __lock_acquire+0x2aca/0x3a20  lock_acquire+0x19b/0x520  _raw_spin_lock+0x2b/0x40  attribute_container_unregister+0x30/0x160  fc_release_transport+0x19/0x90 [scsi_transport_fc]  bfad_im_module_exit+0x23/0x60 [bfa]  bfad_init+0xdb/0xff0 [bfa]  do_one_initcall+0xdc/0x550  do_init_module+0x22d/0x6b0  load_module+0x4e96/0x5ff0  init_module_from_file+0xcd/0x130  idempotent_init_module+0x330/0x620  __x64_sys_finit_module+0xb3/0x110  do_syscall_64+0xc1/0x1d0  entry_SYSCALL_64_after_hwframe+0x77/0x7f  &lt;/TASK&gt;  Allocated by task 25303:  kasan_save_stack+0x24/0x50  kasan_save_track+0x14/0x30  __kasan_kmalloc+0x7f/0x90  fc_attach_transport+0x4f/0x4740 [scsi_transport_fc]  bfad_im_module_init+0x17/0x80 [bfa]  bfad_init+0x23/0xff0 [bfa]  do_one_initcall+0xdc/0x550  do_init_module+0x22d/0x6b0  load_module+0x4e96/0x5ff0  init_module_from_file+0xcd/0x130  idempotent_init_module+0x330/0x620  __x64_sys_finit_module+0xb3/0x110  do_syscall_64+0xc1/0x1d0  entry_SYSCALL_64_after_hwframe+0x77/0x7f  Freed by task 25303:  kasan_save_stack+0x24/0x50  kasan_save_track+0x14/0x30  kasan_save_free_info+0x3b/0x60  __kasan_slab_free+0x38/0x50  kfree+0x212/0x480  bfad_im_module_init+0x7e/0x80 [bfa]  bfad_init+0x23/0xff0 [bfa]  do_one_initcall+0xdc/0x550  do_init_module+0x22d/0x6b0  load_module+0x4e96/0x5ff0  init_module_from_file+0xcd/0x130  idempotent_init_module+0x330/0x620  __x64_sys_finit_module+0xb3/0x110  do_syscall_64+0xc1/0x1d0  entry_SYSCALL_64_after_hwframe+0x77/0x7f  Above issue happens as follows:  bfad_init   error = bfad_im_module_init()     fc_release_transport(bfad_im_scsi_transport_template);   if (error)     goto ext;  ext:   bfad_im_module_exit();     fc_release_transport(bfad_im_scsi_transport_template);     --&gt; Trigger double release  Don&#39;t call bfad_im_module_exit() if bfad_im_module_init() failed.(CVE-2024-53227)In the Linux kernel, the following vulnerability has been resolved:  drm: zynqmp_kms: Unplug DRM device before removal  Prevent userspace accesses to the DRM device from causing use-after-frees by unplugging the device before we remove it. This causes any further userspace accesses to result in an error without further calls into this driver&#39;s internals.(CVE-2024-56538)In the Linux kernel, the following vulnerability has been resolved:  hfsplus: don&#39;t query the device logical block size multiple times  Devices block sizes may change. One of these cases is a loop device by using ioctl LOOP_SET_BLOCK_SIZE.  While this may cause other issues like IO being rejected, in the case of hfsplus, it will allocate a block by using that size and potentially write out-of-bounds when hfsplus_read_wrapper calls hfsplus_submit_bio and the latter function reads a different io_size.  Using a new min_io_size initally set to sb_min_blocksize works for the purposes of the original fix, since it will be set to the max between HFSPLUS_SECTOR_SIZE and the first seen logical block size. We still use the max between HFSPLUS_SECTOR_SIZE and min_io_size in case the latter is not initialized.  Tested by mounting an hfsplus filesystem with loop block sizes 512, 1024 and 4096.  The produced KASAN report before the fix looks like this:  [  419.944641] ================================================================== [  419.945655] BUG: KASAN: slab-use-after-free in hfsplus_read_wrapper+0x659/0xa0a [  419.946703] Read of size 2 at addr ffff88800721fc00 by task repro/10678 [  419.947612] [  419.947846] CPU: 0 UID: 0 PID: 10678 Comm: repro Not tainted 6.12.0-rc5-00008-gdf56e0f2f3ca #84 [  419.949007] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [  419.950035] Call Trace: [  419.950384]  &lt;TASK&gt; [  419.950676]  dump_stack_lvl+0x57/0x78 [  419.951212]  ? hfsplus_read_wrapper+0x659/0xa0a [  419.951830]  print_report+0x14c/0x49e [  419.952361]  ? __virt_addr_valid+0x267/0x278 [  419.952979]  ? kmem_cache_debug_flags+0xc/0x1d [  419.953561]  ? hfsplus_read_wrapper+0x659/0xa0a [  419.954231]  kasan_report+0x89/0xb0 [  419.954748]  ? hfsplus_read_wrapper+0x659/0xa0a [  419.955367]  hfsplus_read_wrapper+0x659/0xa0a [  419.955948]  ? __pfx_hfsplus_read_wrapper+0x10/0x10 [  419.956618]  ? do_raw_spin_unlock+0x59/0x1a9 [  419.957214]  ? _raw_spin_unlock+0x1a/0x2e [  419.957772]  hfsplus_fill_super+0x348/0x1590 [  419.958355]  ? hlock_class+0x4c/0x109 [  419.958867]  ? __pfx_hfsplus_fill_super+0x10/0x10 [  419.959499]  ? __pfx_string+0x10/0x10 [  419.960006]  ? lock_acquire+0x3e2/0x454 [  419.960532]  ? bdev_name.constprop.0+0xce/0x243 [  419.961129]  ? __pfx_bdev_name.constprop.0+0x10/0x10 [  419.961799]  ? pointer+0x3f0/0x62f [  419.962277]  ? __pfx_pointer+0x10/0x10 [  419.962761]  ? vsnprintf+0x6c4/0xfba [  419.963178]  ? __pfx_vsnprintf+0x10/0x10 [  419.963621]  ? setup_bdev_super+0x376/0x3b3 [  419.964029]  ? snprintf+0x9d/0xd2 [  419.964344]  ? __pfx_snprintf+0x10/0x10 [  419.964675]  ? lock_acquired+0x45c/0x5e9 [  419.965016]  ? set_blocksize+0x139/0x1c1 [  419.965381]  ? sb_set_blocksize+0x6d/0xae [  419.965742]  ? __pfx_hfsplus_fill_super+0x10/0x10 [  419.966179]  mount_bdev+0x12f/0x1bf [  419.966512]  ? __pfx_mount_bdev+0x10/0x10 [  419.966886]  ? vfs_parse_fs_string+0xce/0x111 [  419.967293]  ? __pfx_vfs_parse_fs_string+0x10/0x10 [  419.967702]  ? __pfx_hfsplus_mount+0x10/0x10 [  419.968073]  legacy_get_tree+0x104/0x178 [  419.968414]  vfs_get_tree+0x86/0x296 [  419.968751]  path_mount+0xba3/0xd0b [  419.969157]  ? __pfx_path_mount+0x10/0x10 [  419.969594]  ? kmem_cache_free+0x1e2/0x260 [  419.970311]  do_mount+0x99/0xe0 [  419.970630]  ? __pfx_do_mount+0x10/0x10 [  419.971008]  __do_sys_mount+0x199/0x1c9 [  419.971397]  do_syscall_64+0xd0/0x135 [  419.971761]  entry_SYSCALL_64_after_hwframe+0x76/0x7e [  419.972233] RIP: 0033:0x7c3cb812972e [  419.972564] Code: 48 8b 0d f5 46 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 a5 00 00 00 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d c2 46 0d 00 f7 d8 64 89 01 48 [  419.974371] RSP: 002b:00007ffe30632548 EFLAGS: 00000286 ORIG_RAX: 00000000000000a5 [  419.975048] RAX: ffffffffffffffda RBX: 00007ffe306328d8 RCX: 00007c3cb812972e [  419.975701] RDX: 0000000020000000 RSI: 0000000020000c80 RDI: ---truncated---(CVE-2024-56548)In the Linux kernel, the following vulnerability has been resolved:  i3c: master: Fix miss free init_dyn_addr at i3c_master_put_i3c_addrs()  if (dev-&gt;boardinfo &amp;&amp; dev-&gt;boardinfo-&gt;init_dyn_addr)                                       ^^^ here check &#34;init_dyn_addr&#34;  i3c_bus_set_addr_slot_status(&amp;master-&gt;bus, dev-&gt;info.dyn_addr, ...)                    ^^^^        free &#34;dyn_addr&#34; Fix copy/paste error &#34;dyn_addr&#34; by replacing it with &#34;init_dyn_addr&#34;.(CVE-2024-56562)In the Linux kernel, the following vulnerability has been resolved:  ftrace: Fix regression with module command in stack_trace_filter  When executing the following command:      # echo &#34;write*:mod:ext3&#34; &gt; /sys/kernel/tracing/stack_trace_filter  The current mod command causes a null pointer dereference. While commit 0f17976568b3f (&#34;ftrace: Fix regression with module command in stack_trace_filter&#34;) has addressed part of the issue, it left a corner case unhandled, which still results in a kernel crash.(CVE-2024-56569)In the Linux kernel, the following vulnerability has been resolved:  ovl: Filter invalid inodes with missing lookup function  Add a check to the ovl_dentry_weird() function to prevent the processing of directory inodes that lack the lookup function. This is important because such inodes can cause errors in overlayfs when passed to the lowerstack.(CVE-2024-56570)In the Linux kernel, the following vulnerability has been resolved:  media: platform: allegro-dvt: Fix possible memory leak in allocate_buffers_internal()  The buffer in the loop should be released under the exception path, otherwise there may be a memory leak here.  To mitigate this, free the buffer when allegro_alloc_buffer fails.(CVE-2024-56572)In the Linux kernel, the following vulnerability has been resolved:  btrfs: ref-verify: fix use-after-free after invalid ref action  At btrfs_ref_tree_mod() after we successfully inserted the new ref entry (local variable &#39;ref&#39;) into the respective block entry&#39;s rbtree (local variable &#39;be&#39;), if we find an unexpected action of BTRFS_DROP_DELAYED_REF, we error out and free the ref entry without removing it from the block entry&#39;s rbtree. Then in the error path of btrfs_ref_tree_mod() we call btrfs_free_ref_cache(), which iterates over all block entries and then calls free_block_entry() for each one, and there we will trigger a use-after-free when we are called against the block entry to which we added the freed ref entry to its rbtree, since the rbtree still points to the block entry, as we didn&#39;t remove it from the rbtree before freeing it in the error path at btrfs_ref_tree_mod(). Fix this by removing the new ref entry from the rbtree before freeing it.  Syzbot report this with the following stack traces:     BTRFS error (device loop0 state EA):   Ref action 2, root 5, ref_root 0, parent 8564736, owner 0, offset 0, num_refs 18446744073709551615       __btrfs_mod_ref+0x7dd/0xac0 fs/btrfs/extent-tree.c:2523       update_ref_for_cow+0x9cd/0x11f0 fs/btrfs/ctree.c:512       btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594       btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754       btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116       btrfs_insert_empty_items+0x9c/0x1a0 fs/btrfs/ctree.c:4314       btrfs_insert_empty_item fs/btrfs/ctree.h:669 [inline]       btrfs_insert_orphan_item+0x1f1/0x320 fs/btrfs/orphan.c:23       btrfs_orphan_add+0x6d/0x1a0 fs/btrfs/inode.c:3482       btrfs_unlink+0x267/0x350 fs/btrfs/inode.c:4293       vfs_unlink+0x365/0x650 fs/namei.c:4469       do_unlinkat+0x4ae/0x830 fs/namei.c:4533       __do_sys_unlinkat fs/namei.c:4576 [inline]       __se_sys_unlinkat fs/namei.c:4569 [inline]       __x64_sys_unlinkat+0xcc/0xf0 fs/namei.c:4569       do_syscall_x64 arch/x86/entry/common.c:52 [inline]       do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83       entry_SYSCALL_64_after_hwframe+0x77/0x7f    BTRFS error (device loop0 state EA):   Ref action 1, root 5, ref_root 5, parent 0, owner 260, offset 0, num_refs 1       __btrfs_mod_ref+0x76b/0xac0 fs/btrfs/extent-tree.c:2521       update_ref_for_cow+0x96a/0x11f0       btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594       btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754       btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116       btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:411       __btrfs_update_delayed_inode+0x1e7/0xb90 fs/btrfs/delayed-inode.c:1030       btrfs_update_delayed_inode fs/btrfs/delayed-inode.c:1114 [inline]       __btrfs_commit_inode_delayed_items+0x2318/0x24a0 fs/btrfs/delayed-inode.c:1137       __btrfs_run_delayed_items+0x213/0x490 fs/btrfs/delayed-inode.c:1171       btrfs_commit_transaction+0x8a8/0x3740 fs/btrfs/transaction.c:2313       prepare_to_relocate+0x3c4/0x4c0 fs/btrfs/relocation.c:3586       relocate_block_group+0x16c/0xd40 fs/btrfs/relocation.c:3611       btrfs_relocate_block_group+0x77d/0xd90 fs/btrfs/relocation.c:4081       btrfs_relocate_chunk+0x12c/0x3b0 fs/btrfs/volumes.c:3377       __btrfs_balance+0x1b0f/0x26b0 fs/btrfs/volumes.c:4161       btrfs_balance+0xbdc/0x10c0 fs/btrfs/volumes.c:4538    BTRFS error (device loop0 state EA):   Ref action 2, root 5, ref_root 0, parent 8564736, owner 0, offset 0, num_refs 18446744073709551615       __btrfs_mod_ref+0x7dd/0xac0 fs/btrfs/extent-tree.c:2523       update_ref_for_cow+0x9cd/0x11f0 fs/btrfs/ctree.c:512       btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594       btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754       btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116       btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:411       __btrfs_update_delayed_inode+0x1e7/0xb90 fs/btrfs/delayed-inode.c:1030       btrfs_update_delayed_i ---truncated---(CVE-2024-56581)In the Linux kernel, the following vulnerability has been resolved:  sched/deadline: Fix warning in migrate_enable for boosted tasks  When running the following command:  while true; do     stress-ng --cyclic 30 --timeout 30s --minimize --quiet done  a warning is eventually triggered:  WARNING: CPU: 43 PID: 2848 at kernel/sched/deadline.c:794 setup_new_dl_entity+0x13e/0x180 ... Call Trace:  &lt;TASK&gt;  ? show_trace_log_lvl+0x1c4/0x2df  ? enqueue_dl_entity+0x631/0x6e0  ? setup_new_dl_entity+0x13e/0x180  ? __warn+0x7e/0xd0  ? report_bug+0x11a/0x1a0  ? handle_bug+0x3c/0x70  ? exc_invalid_op+0x14/0x70  ? asm_exc_invalid_op+0x16/0x20  enqueue_dl_entity+0x631/0x6e0  enqueue_task_dl+0x7d/0x120  __do_set_cpus_allowed+0xe3/0x280  __set_cpus_allowed_ptr_locked+0x140/0x1d0  __set_cpus_allowed_ptr+0x54/0xa0  migrate_enable+0x7e/0x150  rt_spin_unlock+0x1c/0x90  group_send_sig_info+0xf7/0x1a0  ? kill_pid_info+0x1f/0x1d0  kill_pid_info+0x78/0x1d0  kill_proc_info+0x5b/0x110  __x64_sys_kill+0x93/0xc0  do_syscall_64+0x5c/0xf0  entry_SYSCALL_64_after_hwframe+0x6e/0x76  RIP: 0033:0x7f0dab31f92b  This warning occurs because set_cpus_allowed dequeues and enqueues tasks with the ENQUEUE_RESTORE flag set. If the task is boosted, the warning is triggered. A boosted task already had its parameters set by rt_mutex_setprio, and a new call to setup_new_dl_entity is unnecessary, hence the WARN_ON call.  Check if we are requeueing a boosted task and avoid calling setup_new_dl_entity if that&#39;s the case.(CVE-2024-56583)In the Linux kernel, the following vulnerability has been resolved:  io_uring/tctx: work around xa_store() allocation error issue  syzbot triggered the following WARN_ON:  WARNING: CPU: 0 PID: 16 at io_uring/tctx.c:51 __io_uring_free+0xfa/0x140 io_uring/tctx.c:51  which is the  WARN_ON_ONCE(!xa_empty(&amp;tctx-&gt;xa));  sanity check in __io_uring_free() when a io_uring_task is going through its final put. The syzbot test case includes injecting memory allocation failures, and it very much looks like xa_store() can fail one of its memory allocations and end up with -&gt;head being non-NULL even though no entries exist in the xarray.  Until this issue gets sorted out, work around it by attempting to iterate entries in our xarray, and WARN_ON_ONCE() if one is found.(CVE-2024-56584)In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix f2fs_bug_on when uninstalling filesystem call f2fs_evict_inode.  creating a large files during checkpoint disable until it runs out of space and then delete it, then remount to enable checkpoint again, and then unmount the filesystem triggers the f2fs_bug_on as below:  ------------[ cut here ]------------ kernel BUG at fs/f2fs/inode.c:896! CPU: 2 UID: 0 PID: 1286 Comm: umount Not tainted 6.11.0-rc7-dirty #360 Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:f2fs_evict_inode+0x58c/0x610 Call Trace:  __die_body+0x15/0x60  die+0x33/0x50  do_trap+0x10a/0x120  f2fs_evict_inode+0x58c/0x610  do_error_trap+0x60/0x80  f2fs_evict_inode+0x58c/0x610  exc_invalid_op+0x53/0x60  f2fs_evict_inode+0x58c/0x610  asm_exc_invalid_op+0x16/0x20  f2fs_evict_inode+0x58c/0x610  evict+0x101/0x260  dispose_list+0x30/0x50  evict_inodes+0x140/0x190  generic_shutdown_super+0x2f/0x150  kill_block_super+0x11/0x40  kill_f2fs_super+0x7d/0x140  deactivate_locked_super+0x2a/0x70  cleanup_mnt+0xb3/0x140  task_work_run+0x61/0x90  The root cause is: creating large files during disable checkpoint period results in not enough free segments, so when writing back root inode will failed in f2fs_enable_checkpoint. When umount the file system after enabling checkpoint, the root inode is dirty in f2fs_evict_inode function, which triggers BUG_ON. The steps to reproduce are as follows:  dd if=/dev/zero of=f2fs.img bs=1M count=55 mount f2fs.img f2fs_dir -o checkpoint=disable:10% dd if=/dev/zero of=big bs=1M count=50 sync rm big mount -o remount,checkpoint=enable f2fs_dir umount f2fs_dir  Let&#39;s redirty inode when there is not free segments during checkpoint is disable.(CVE-2024-56586)In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu: set the right AMDGPU sg segment limitation  The driver needs to set the correct max_segment_size; otherwise debug_dma_map_sg() will complain about the over-mapping of the AMDGPU sg length as following:  WARNING: CPU: 6 PID: 1964 at kernel/dma/debug.c:1178 debug_dma_map_sg+0x2dc/0x370 [  364.049444] Modules linked in: veth amdgpu(OE) amdxcp drm_exec gpu_sched drm_buddy drm_ttm_helper ttm(OE) drm_suballoc_helper drm_display_helper drm_kms_helper i2c_algo_bit rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace netfs xt_conntrack xt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo iptable_nat xt_addrtype iptable_filter br_netfilter nvme_fabrics overlay nfnetlink_cttimeout nfnetlink openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c bridge stp llc amd_atl intel_rapl_msr intel_rapl_common sunrpc sch_fq_codel snd_hda_codec_realtek snd_hda_codec_generic snd_hda_scodec_component snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg edac_mce_amd binfmt_misc snd_hda_codec snd_pci_acp6x snd_hda_core snd_acp_config snd_hwdep snd_soc_acpi kvm_amd snd_pcm kvm snd_seq_midi snd_seq_midi_event crct10dif_pclmul ghash_clmulni_intel sha512_ssse3 snd_rawmidi sha256_ssse3 sha1_ssse3 aesni_intel snd_seq nls_iso8859_1 crypto_simd snd_seq_device cryptd snd_timer rapl input_leds snd [  364.049532]  ipmi_devintf wmi_bmof ccp serio_raw k10temp sp5100_tco soundcore ipmi_msghandler cm32181 industrialio mac_hid msr parport_pc ppdev lp parport drm efi_pstore ip_tables x_tables pci_stub crc32_pclmul nvme ahci libahci i2c_piix4 r8169 nvme_core i2c_designware_pci realtek i2c_ccgx_ucsi video wmi hid_generic cdc_ether usbnet usbhid hid r8152 mii [  364.049576] CPU: 6 PID: 1964 Comm: rocminfo Tainted: G           OE      6.10.0-custom #492 [  364.049579] Hardware name: AMD Majolica-RN/Majolica-RN, BIOS RMJ1009A 06/13/2021 [  364.049582] RIP: 0010:debug_dma_map_sg+0x2dc/0x370 [  364.049585] Code: 89 4d b8 e8 36 b1 86 00 8b 4d b8 48 8b 55 b0 44 8b 45 a8 4c 8b 4d a0 48 89 c6 48 c7 c7 00 4b 74 bc 4c 89 4d b8 e8 b4 73 f3 ff &lt;0f&gt; 0b 4c 8b 4d b8 8b 15 c8 2c b8 01 85 d2 0f 85 ee fd ff ff 8b 05 [  364.049588] RSP: 0018:ffff9ca600b57ac0 EFLAGS: 00010286 [  364.049590] RAX: 0000000000000000 RBX: ffff88b7c132b0c8 RCX: 0000000000000027 [  364.049592] RDX: ffff88bb0f521688 RSI: 0000000000000001 RDI: ffff88bb0f521680 [  364.049594] RBP: ffff9ca600b57b20 R08: 000000000000006f R09: ffff9ca600b57930 [  364.049596] R10: ffff9ca600b57928 R11: ffffffffbcb46328 R12: 0000000000000000 [  364.049597] R13: 0000000000000001 R14: ffff88b7c19c0700 R15: ffff88b7c9059800 [  364.049599] FS:  00007fb2d3516e80(0000) GS:ffff88bb0f500000(0000) knlGS:0000000000000000 [  364.049601] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [  364.049603] CR2: 000055610bd03598 CR3: 00000001049f6000 CR4: 0000000000350ef0 [  364.049605] Call Trace: [  364.049607]  &lt;TASK&gt; [  364.049609]  ? show_regs+0x6d/0x80 [  364.049614]  ? __warn+0x8c/0x140 [  364.049618]  ? debug_dma_map_sg+0x2dc/0x370 [  364.049621]  ? report_bug+0x193/0x1a0 [  364.049627]  ? handle_bug+0x46/0x80 [  364.049631]  ? exc_invalid_op+0x1d/0x80 [  364.049635]  ? asm_exc_invalid_op+0x1f/0x30 [  364.049642]  ? debug_dma_map_sg+0x2dc/0x370 [  364.049647]  __dma_map_sg_attrs+0x90/0xe0 [  364.049651]  dma_map_sgtable+0x25/0x40 [  364.049654]  amdgpu_bo_move+0x59a/0x850 [amdgpu] [  364.049935]  ? srso_return_thunk+0x5/0x5f [  364.049939]  ? amdgpu_ttm_tt_populate+0x5d/0xc0 [amdgpu] [  364.050095]  ttm_bo_handle_move_mem+0xc3/0x180 [ttm] [  364.050103]  ttm_bo_validate+0xc1/0x160 [ttm] [  364.050108]  ? amdgpu_ttm_tt_get_user_pages+0xe5/0x1b0 [amdgpu] [  364.050263]  amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0xa12/0xc90 [amdgpu] [  364.050473]  kfd_ioctl_alloc_memory_of_gpu+0x16b/0x3b0 [amdgpu] [  364.050680]  kfd_ioctl+0x3c2/0x530 [amdgpu] [  364.050866]  ? __pfx_kfd_ioctl_alloc_memory_of_gpu+0x10/0x10 [amdgpu] [  364.05105 ---truncated---(CVE-2024-56594)In the Linux kernel, the following vulnerability has been resolved:  jfs: fix array-index-out-of-bounds in jfs_readdir  The stbl might contain some invalid values. Added a check to return error code in that case.(CVE-2024-56596)In the Linux kernel, the following vulnerability has been resolved:  jfs: array-index-out-of-bounds fix in dtReadFirst  The value of stbl can be sometimes out of bounds due to a bad filesystem. Added a check with appopriate return of error code in that case.(CVE-2024-56598)In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: RFCOMM: avoid leaving dangling sk pointer in rfcomm_sock_alloc()  bt_sock_alloc() attaches allocated sk object to the provided sock object. If rfcomm_dlc_alloc() fails, we release the sk object, but leave the dangling pointer in the sock object, which may cause use-after-free.  Fix this by swapping calls to bt_sock_alloc() and rfcomm_dlc_alloc().(CVE-2024-56604)In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: L2CAP: do not leave dangling sk pointer on error in l2cap_sock_create()  bt_sock_alloc() allocates the sk object and attaches it to the provided sock object. On error l2cap_sock_alloc() frees the sk object, but the dangling pointer is still attached to the sock object, which may create use-after-free in other code.(CVE-2024-56605)In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Fix out-of-bounds access in &#39;dcn21_link_encoder_create&#39;  An issue was identified in the dcn21_link_encoder_create function where an out-of-bounds access could occur when the hpd_source index was used to reference the link_enc_hpd_regs array. This array has a fixed size and the index was not being checked against the array&#39;s bounds before accessing it.  This fix adds a conditional check to ensure that the hpd_source index is within the valid range of the link_enc_hpd_regs array. If the index is out of bounds, the function now returns NULL to prevent undefined behavior.  References:  [   65.920507] ------------[ cut here ]------------ [   65.920510] UBSAN: array-index-out-of-bounds in drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn21/dcn21_resource.c:1312:29 [   65.920519] index 7 is out of range for type &#39;dcn10_link_enc_hpd_registers [5]&#39; [   65.920523] CPU: 3 PID: 1178 Comm: modprobe Tainted: G           OE      6.8.0-cleanershaderfeatureresetasdntipmi200nv2132 #13 [   65.920525] Hardware name: AMD Majolica-RN/Majolica-RN, BIOS WMJ0429N_Weekly_20_04_2 04/29/2020 [   65.920527] Call Trace: [   65.920529]  &lt;TASK&gt; [   65.920532]  dump_stack_lvl+0x48/0x70 [   65.920541]  dump_stack+0x10/0x20 [   65.920543]  __ubsan_handle_out_of_bounds+0xa2/0xe0 [   65.920549]  dcn21_link_encoder_create+0xd9/0x140 [amdgpu] [   65.921009]  link_create+0x6d3/0xed0 [amdgpu] [   65.921355]  create_links+0x18a/0x4e0 [amdgpu] [   65.921679]  dc_create+0x360/0x720 [amdgpu] [   65.921999]  ? dmi_matches+0xa0/0x220 [   65.922004]  amdgpu_dm_init+0x2b6/0x2c90 [amdgpu] [   65.922342]  ? console_unlock+0x77/0x120 [   65.922348]  ? dev_printk_emit+0x86/0xb0 [   65.922354]  dm_hw_init+0x15/0x40 [amdgpu] [   65.922686]  amdgpu_device_init+0x26a8/0x33a0 [amdgpu] [   65.922921]  amdgpu_driver_load_kms+0x1b/0xa0 [amdgpu] [   65.923087]  amdgpu_pci_probe+0x1b7/0x630 [amdgpu] [   65.923087]  local_pci_probe+0x4b/0xb0 [   65.923087]  pci_device_probe+0xc8/0x280 [   65.923087]  really_probe+0x187/0x300 [   65.923087]  __driver_probe_device+0x85/0x130 [   65.923087]  driver_probe_device+0x24/0x110 [   65.923087]  __driver_attach+0xac/0x1d0 [   65.923087]  ? __pfx___driver_attach+0x10/0x10 [   65.923087]  bus_for_each_dev+0x7d/0xd0 [   65.923087]  driver_attach+0x1e/0x30 [   65.923087]  bus_add_driver+0xf2/0x200 [   65.923087]  driver_register+0x64/0x130 [   65.923087]  ? __pfx_amdgpu_init+0x10/0x10 [amdgpu] [   65.923087]  __pci_register_driver+0x61/0x70 [   65.923087]  amdgpu_init+0x7d/0xff0 [amdgpu] [   65.923087]  do_one_initcall+0x49/0x310 [   65.923087]  ? kmalloc_trace+0x136/0x360 [   65.923087]  do_init_module+0x6a/0x270 [   65.923087]  load_module+0x1fce/0x23a0 [   65.923087]  init_module_from_file+0x9c/0xe0 [   65.923087]  ? init_module_from_file+0x9c/0xe0 [   65.923087]  idempotent_init_module+0x179/0x230 [   65.923087]  __x64_sys_finit_module+0x5d/0xa0 [   65.923087]  do_syscall_64+0x76/0x120 [   65.923087]  entry_SYSCALL_64_after_hwframe+0x6e/0x76 [   65.923087] RIP: 0033:0x7f2d80f1e88d [   65.923087] Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 b5 0f 00 f7 d8 64 89 01 48 [   65.923087] RSP: 002b:00007ffc7bc1aa78 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [   65.923087] RAX: ffffffffffffffda RBX: 0000564c9c1db130 RCX: 00007f2d80f1e88d [   65.923087] RDX: 0000000000000000 RSI: 0000564c9c1e5480 RDI: 000000000000000f [   65.923087] RBP: 0000000000040000 R08: 0000000000000000 R09: 0000000000000002 [   65.923087] R10: 000000000000000f R11: 0000000000000246 R12: 0000564c9c1e5480 [   65.923087] R13: 0000564c9c1db260 R14: 0000000000000000 R15: 0000564c9c1e54b0 [   65.923087]  &lt;/TASK&gt; [   65.923927] ---[ end trace ]---(CVE-2024-56608)In the Linux kernel, the following vulnerability has been resolved:  bpf: fix OOB devmap writes when deleting elements  Jordy reported issue against XSKMAP which also applies to DEVMAP - the index used for accessing map entry, due to being a signed integer, causes the OOB writes. Fix is simple as changing the type from int to u32, however, when compared to XSKMAP case, one more thing needs to be addressed.  When map is released from system via dev_map_free(), we iterate through all of the entries and an iterator variable is also an int, which implies OOB accesses. Again, change it to be u32.  Example splat below:  [  160.724676] BUG: unable to handle page fault for address: ffffc8fc2c001000 [  160.731662] #PF: supervisor read access in kernel mode [  160.736876] #PF: error_code(0x0000) - not-present page [  160.742095] PGD 0 P4D 0 [  160.744678] Oops: Oops: 0000 [#1] PREEMPT SMP [  160.749106] CPU: 1 UID: 0 PID: 520 Comm: kworker/u145:12 Not tainted 6.12.0-rc1+ #487 [  160.757050] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019 [  160.767642] Workqueue: events_unbound bpf_map_free_deferred [  160.773308] RIP: 0010:dev_map_free+0x77/0x170 [  160.777735] Code: 00 e8 fd 91 ed ff e8 b8 73 ed ff 41 83 7d 18 19 74 6e 41 8b 45 24 49 8b bd f8 00 00 00 31 db 85 c0 74 48 48 63 c3 48 8d 04 c7 &lt;48&gt; 8b 28 48 85 ed 74 30 48 8b 7d 18 48 85 ff 74 05 e8 b3 52 fa ff [  160.796777] RSP: 0018:ffffc9000ee1fe38 EFLAGS: 00010202 [  160.802086] RAX: ffffc8fc2c001000 RBX: 0000000080000000 RCX: 0000000000000024 [  160.809331] RDX: 0000000000000000 RSI: 0000000000000024 RDI: ffffc9002c001000 [  160.816576] RBP: 0000000000000000 R08: 0000000000000023 R09: 0000000000000001 [  160.823823] R10: 0000000000000001 R11: 00000000000ee6b2 R12: dead000000000122 [  160.831066] R13: ffff88810c928e00 R14: ffff8881002df405 R15: 0000000000000000 [  160.838310] FS:  0000000000000000(0000) GS:ffff8897e0c40000(0000) knlGS:0000000000000000 [  160.846528] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [  160.852357] CR2: ffffc8fc2c001000 CR3: 0000000005c32006 CR4: 00000000007726f0 [  160.859604] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [  160.866847] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [  160.874092] PKRU: 55555554 [  160.876847] Call Trace: [  160.879338]  &lt;TASK&gt; [  160.881477]  ? __die+0x20/0x60 [  160.884586]  ? page_fault_oops+0x15a/0x450 [  160.888746]  ? search_extable+0x22/0x30 [  160.892647]  ? search_bpf_extables+0x5f/0x80 [  160.896988]  ? exc_page_fault+0xa9/0x140 [  160.900973]  ? asm_exc_page_fault+0x22/0x30 [  160.905232]  ? dev_map_free+0x77/0x170 [  160.909043]  ? dev_map_free+0x58/0x170 [  160.912857]  bpf_map_free_deferred+0x51/0x90 [  160.917196]  process_one_work+0x142/0x370 [  160.921272]  worker_thread+0x29e/0x3b0 [  160.925082]  ? rescuer_thread+0x4b0/0x4b0 [  160.929157]  kthread+0xd4/0x110 [  160.932355]  ? kthread_park+0x80/0x80 [  160.936079]  ret_from_fork+0x2d/0x50 [  160.943396]  ? kthread_park+0x80/0x80 [  160.950803]  ret_from_fork_asm+0x11/0x20 [  160.958482]  &lt;/TASK&gt;(CVE-2024-56615)In the Linux kernel, the following vulnerability has been resolved:  nilfs2: fix potential out-of-bounds memory access in nilfs_find_entry()  Syzbot reported that when searching for records in a directory where the inode&#39;s i_size is corrupted and has a large value, memory access outside the folio/page range may occur, or a use-after-free bug may be detected if KASAN is enabled.  This is because nilfs_last_byte(), which is called by nilfs_find_entry() and others to calculate the number of valid bytes of directory data in a page from i_size and the page index, loses the upper 32 bits of the 64-bit size information due to an inappropriate type of local variable to which the i_size value is assigned.  This caused a large byte offset value due to underflow in the end address calculation in the calling nilfs_find_entry(), resulting in memory access that exceeds the folio/page size.  Fix this issue by changing the type of the local variable causing the bit loss from &#34;unsigned int&#34; to &#34;u64&#34;.  The return value of nilfs_last_byte() is also of type &#34;unsigned int&#34;, but it is truncated so as not to exceed PAGE_SIZE and no bit loss occurs, so no change is required.(CVE-2024-56619)In the Linux kernel, the following vulnerability has been resolved:  ksmbd: fix Out-of-Bounds Read in ksmbd_vfs_stream_read  An offset from client could be a negative value, It could lead to an out-of-bounds read from the stream_buf. Note that this issue is coming when setting &#39;vfs objects = streams_xattr parameter&#39; in ksmbd.conf.(CVE-2024-56627)In the Linux kernel, the following vulnerability has been resolved:  HID: wacom: fix when get product name maybe null pointer  Due to incorrect dev-&gt;product reporting by certain devices, null pointer dereferences occur when dev-&gt;product is empty, leading to potential system crashes.  This issue was found on EXCELSIOR DL37-D05 device with Loongson-LS3A6000-7A2000-DL37 motherboard.  Kernel logs: [   56.470885] usb 4-3: new full-speed USB device number 4 using ohci-pci [   56.671638] usb 4-3: string descriptor 0 read error: -22 [   56.671644] usb 4-3: New USB device found, idVendor=056a, idProduct=0374, bcdDevice= 1.07 [   56.671647] usb 4-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [   56.678839] hid-generic 0003:056A:0374.0004: hiddev0,hidraw3: USB HID v1.10 Device [HID 056a:0374] on usb-0000:00:05.0-3/input0 [   56.697719] CPU 2 Unable to handle kernel paging request at virtual address 0000000000000000, era == 90000000066e35c8, ra == ffff800004f98a80 [   56.697732] Oops[#1]: [   56.697734] CPU: 2 PID: 2742 Comm: (udev-worker) Tainted: G           OE      6.6.0-loong64-desktop #25.00.2000.015 [   56.697737] Hardware name: Inspur CE520L2/C09901N000000000, BIOS 2.09.00 10/11/2024 [   56.697739] pc 90000000066e35c8 ra ffff800004f98a80 tp 9000000125478000 sp 900000012547b8a0 [   56.697741] a0 0000000000000000 a1 ffff800004818b28 a2 0000000000000000 a3 0000000000000000 [   56.697743] a4 900000012547b8f0 a5 0000000000000000 a6 0000000000000000 a7 0000000000000000 [   56.697745] t0 ffff800004818b2d t1 0000000000000000 t2 0000000000000003 t3 0000000000000005 [   56.697747] t4 0000000000000000 t5 0000000000000000 t6 0000000000000000 t7 0000000000000000 [   56.697748] t8 0000000000000000 u0 0000000000000000 s9 0000000000000000 s0 900000011aa48028 [   56.697750] s1 0000000000000000 s2 0000000000000000 s3 ffff800004818e80 s4 ffff800004810000 [   56.697751] s5 90000001000b98d0 s6 ffff800004811f88 s7 ffff800005470440 s8 0000000000000000 [   56.697753]    ra: ffff800004f98a80 wacom_update_name+0xe0/0x300 [wacom] [   56.697802]   ERA: 90000000066e35c8 strstr+0x28/0x120 [   56.697806]  CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) [   56.697816]  PRMD: 0000000c (PPLV0 +PIE +PWE) [   56.697821]  EUEN: 00000000 (-FPE -SXE -ASXE -BTE) [   56.697827]  ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7) [   56.697831] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0) [   56.697835]  BADV: 0000000000000000 [   56.697836]  PRID: 0014d000 (Loongson-64bit, Loongson-3A6000) [   56.697838] Modules linked in: wacom(+) bnep bluetooth rfkill qrtr nls_iso8859_1 nls_cp437 snd_hda_codec_conexant snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_timer snd soundcore input_leds mousedev led_class joydev deepin_netmonitor(OE) fuse nfnetlink dmi_sysfs ip_tables x_tables overlay amdgpu amdxcp drm_exec gpu_sched drm_buddy radeon drm_suballoc_helper i2c_algo_bit drm_ttm_helper r8169 ttm drm_display_helper spi_loongson_pci xhci_pci cec xhci_pci_renesas spi_loongson_core hid_generic realtek gpio_loongson_64bit [   56.697887] Process (udev-worker) (pid: 2742, threadinfo=00000000aee0d8b4, task=00000000a9eff1f3) [   56.697890] Stack : 0000000000000000 ffff800004817e00 0000000000000000 0000251c00000000 [   56.697896]         0000000000000000 00000011fffffffd 0000000000000000 0000000000000000 [   56.697901]         0000000000000000 1b67a968695184b9 0000000000000000 90000001000b98d0 [   56.697906]         90000001000bb8d0 900000011aa48028 0000000000000000 ffff800004f9d74c [   56.697911]         90000001000ba000 ffff800004f9ce58 0000000000000000 ffff800005470440 [   56.697916]         ffff800004811f88 90000001000b98d0 9000000100da2aa8 90000001000bb8d0 [   56.697921]         0000000000000000 90000001000ba000 900000011aa48028 ffff800004f9d74c [   56.697926]         ffff8000054704e8 90000001000bb8b8 90000001000ba000 0000000000000000 [   56.697931]         90000001000bb8d0  ---truncated---(CVE-2024-56629)In the Linux kernel, the following vulnerability has been resolved:  blk-cgroup: Fix UAF in blkcg_unpin_online()  blkcg_unpin_online() walks up the blkcg hierarchy putting the online pin. To walk up, it uses blkcg_parent(blkcg) but it was calling that after blkcg_destroy_blkgs(blkcg) which could free the blkcg, leading to the following UAF:    ==================================================================   BUG: KASAN: slab-use-after-free in blkcg_unpin_online+0x15a/0x270   Read of size 8 at addr ffff8881057678c0 by task kworker/9:1/117    CPU: 9 UID: 0 PID: 117 Comm: kworker/9:1 Not tainted 6.13.0-rc1-work-00182-gb8f52214c61a-dirty #48   Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS unknown 02/02/2022   Workqueue: cgwb_release cgwb_release_workfn   Call Trace:    &lt;TASK&gt;    dump_stack_lvl+0x27/0x80    print_report+0x151/0x710    kasan_report+0xc0/0x100    blkcg_unpin_online+0x15a/0x270    cgwb_release_workfn+0x194/0x480    process_scheduled_works+0x71b/0xe20    worker_thread+0x82a/0xbd0    kthread+0x242/0x2c0    ret_from_fork+0x33/0x70    ret_from_fork_asm+0x1a/0x30    &lt;/TASK&gt;   ...   Freed by task 1944:    kasan_save_track+0x2b/0x70    kasan_save_free_info+0x3c/0x50    __kasan_slab_free+0x33/0x50    kfree+0x10c/0x330    css_free_rwork_fn+0xe6/0xb30    process_scheduled_works+0x71b/0xe20    worker_thread+0x82a/0xbd0    kthread+0x242/0x2c0    ret_from_fork+0x33/0x70    ret_from_fork_asm+0x1a/0x30  Note that the UAF is not easy to trigger as the free path is indirected behind a couple RCU grace periods and a work item execution. I could only trigger it with artifical msleep() injected in blkcg_unpin_online().  Fix it by reading the parent pointer before destroying the blkcg&#39;s blkg&#39;s.(CVE-2024-56672)In the Linux kernel, the following vulnerability has been resolved:  crypto: bcm - add error check in the ahash_hmac_init function  The ahash_init functions may return fails. The ahash_hmac_init should not return ok when ahash_init returns error. For an example, ahash_init will return -ENOMEM when allocation memory is error.(CVE-2024-56681)In the Linux kernel, the following vulnerability has been resolved:  ext4: fix race in buffer_head read fault injection  When I enabled ext4 debug for fault injection testing, I encountered the following warning:    EXT4-fs error (device sda): ext4_read_inode_bitmap:201: comm fsstress:          Cannot read inode bitmap - block_group = 8, inode_bitmap = 1051   WARNING: CPU: 0 PID: 511 at fs/buffer.c:1181 mark_buffer_dirty+0x1b3/0x1d0  The root cause of the issue lies in the improper implementation of ext4&#39;s buffer_head read fault injection. The actual completion of buffer_head read and the buffer_head fault injection are not atomic, which can lead to the uptodate flag being cleared on normally used buffer_heads in race conditions.  [CPU0]           [CPU1]         [CPU2] ext4_read_inode_bitmap   ext4_read_bh()   &lt;bh read complete&gt;                  ext4_read_inode_bitmap                    if (buffer_uptodate(bh))                      return bh                                jbd2_journal_commit_transaction                                  __jbd2_journal_refile_buffer                                    __jbd2_journal_unfile_buffer                                      __jbd2_journal_temp_unlink_buffer   ext4_simulate_fail_bh()     clear_buffer_uptodate                                       mark_buffer_dirty                                         &lt;report warning&gt;                                         WARN_ON_ONCE(!buffer_uptodate(bh))  The best approach would be to perform fault injection in the IO completion callback function, rather than after IO completion. However, the IO completion callback function cannot get the fault injection code in sb.  Fix it by passing the result of fault injection into the bh read function, we simulate faults within the bh read function itself. This requires adding an extra parameter to the bh read functions that need fault injection.(CVE-2024-56686)In the Linux kernel, the following vulnerability has been resolved:  mfd: intel_soc_pmic_bxtwc: Use IRQ domain for USB Type-C device  While design wise the idea of converting the driver to use the hierarchy of the IRQ chips is correct, the implementation has (inherited) flaws. This was unveiled when platform_get_irq() had started WARN() on IRQ 0 that is supposed to be a Linux IRQ number (also known as vIRQ).  Rework the driver to respect IRQ domain when creating each MFD device separately, as the domain is not the same for all of them.(CVE-2024-56691)In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to do sanity check on node blkaddr in truncate_node()  syzbot reports a f2fs bug as below:  ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2534! RIP: 0010:f2fs_invalidate_blocks+0x35f/0x370 fs/f2fs/segment.c:2534 Call Trace:  truncate_node+0x1ae/0x8c0 fs/f2fs/node.c:909  f2fs_remove_inode_page+0x5c2/0x870 fs/f2fs/node.c:1288  f2fs_evict_inode+0x879/0x15c0 fs/f2fs/inode.c:856  evict+0x4e8/0x9b0 fs/inode.c:723  f2fs_handle_failed_inode+0x271/0x2e0 fs/f2fs/inode.c:986  f2fs_create+0x357/0x530 fs/f2fs/namei.c:394  lookup_open fs/namei.c:3595 [inline]  open_last_lookups fs/namei.c:3694 [inline]  path_openat+0x1c03/0x3590 fs/namei.c:3930  do_filp_open+0x235/0x490 fs/namei.c:3960  do_sys_openat2+0x13e/0x1d0 fs/open.c:1415  do_sys_open fs/open.c:1430 [inline]  __do_sys_openat fs/open.c:1446 [inline]  __se_sys_openat fs/open.c:1441 [inline]  __x64_sys_openat+0x247/0x2a0 fs/open.c:1441  do_syscall_x64 arch/x86/entry/common.c:52 [inline]  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0010:f2fs_invalidate_blocks+0x35f/0x370 fs/f2fs/segment.c:2534  The root cause is: on a fuzzed image, blkaddr in nat entry may be corrupted, then it will cause system panic when using it in f2fs_invalidate_blocks(), to avoid this, let&#39;s add sanity check on nat blkaddr in truncate_node().(CVE-2024-56692)In the Linux kernel, the following vulnerability has been resolved:  media: wl128x: Fix atomicity violation in fmc_send_cmd()  Atomicity violation occurs when the fmc_send_cmd() function is executed simultaneously with the modification of the fmdev-&gt;resp_skb value. Consider a scenario where, after passing the validity check within the function, a non-null fmdev-&gt;resp_skb variable is assigned a null value. This results in an invalid fmdev-&gt;resp_skb variable passing the validity check. As seen in the later part of the function, skb = fmdev-&gt;resp_skb; when the invalid fmdev-&gt;resp_skb passes the check, a null pointer dereference error may occur at line 478, evt_hdr = (void *)skb-&gt;data;  To address this issue, it is recommended to include the validity check of fmdev-&gt;resp_skb within the locked section of the function. This modification ensures that the value of fmdev-&gt;resp_skb does not change during the validation process, thereby maintaining its validity.  This possible bug is found by an experimental static analysis tool developed by our team. This tool analyzes the locking APIs to extract function pairs that can be concurrently executed, and then analyzes the instructions in the paired functions to identify possible concurrency bugs including data races and atomicity violations.(CVE-2024-56700)In the Linux kernel, the following vulnerability has been resolved:  io_uring: check if iowq is killed before queuing  task work can be executed after the task has gone through io_uring termination, whether it&#39;s the final task_work run or the fallback path. In this case, task work will find -&gt;io_wq being already killed and null&#39;ed, which is a problem if it then tries to forward the request to io_queue_iowq(). Make io_queue_iowq() fail requests in this case.  Note that it also checks PF_KTHREAD, because the user can first close a DEFER_TASKRUN ring and shortly after kill the task, in which case -&gt;iowq check would race.(CVE-2024-56709)In the Linux kernel, the following vulnerability has been resolved:  rtc: check if __rtc_read_time was successful in rtc_timer_do_work()  If the __rtc_read_time call fails,, the struct rtc_time tm; may contain uninitialized data, or an illegal date/time read from the RTC hardware.  When calling rtc_tm_to_ktime later, the result may be a very large value (possibly KTIME_MAX). If there are periodic timers in rtc-&gt;timerqueue, they will continually expire, may causing kernel softlockup.(CVE-2024-56739)In the Linux kernel, the following vulnerability has been resolved:  apparmor: test: Fix memory leak for aa_unpack_strdup()  The string allocated by kmemdup() in aa_unpack_strdup() is not freed and cause following memory leaks, free them to fix it.   unreferenced object 0xffffff80c6af8a50 (size 8):    comm &#34;kunit_try_catch&#34;, pid 225, jiffies 4294894407    hex dump (first 8 bytes):      74 65 73 74 69 6e 67 00                          testing.    backtrace (crc 5eab668b):      [&lt;0000000001e3714d&gt;] kmemleak_alloc+0x34/0x40      [&lt;000000006e6c7776&gt;] __kmalloc_node_track_caller_noprof+0x300/0x3e0      [&lt;000000006870467c&gt;] kmemdup_noprof+0x34/0x60      [&lt;000000001176bb03&gt;] aa_unpack_strdup+0xd0/0x18c      [&lt;000000008ecde918&gt;] policy_unpack_test_unpack_strdup_with_null_name+0xf8/0x3ec      [&lt;0000000032ef8f77&gt;] kunit_try_run_case+0x13c/0x3ac      [&lt;00000000f3edea23&gt;] kunit_generic_run_threadfn_adapter+0x80/0xec      [&lt;00000000adf936cf&gt;] kthread+0x2e8/0x374      [&lt;0000000041bb1628&gt;] ret_from_fork+0x10/0x20  unreferenced object 0xffffff80c2a29090 (size 8):    comm &#34;kunit_try_catch&#34;, pid 227, jiffies 4294894409    hex dump (first 8 bytes):      74 65 73 74 69 6e 67 00                          testing.    backtrace (crc 5eab668b):      [&lt;0000000001e3714d&gt;] kmemleak_alloc+0x34/0x40      [&lt;000000006e6c7776&gt;] __kmalloc_node_track_caller_noprof+0x300/0x3e0      [&lt;000000006870467c&gt;] kmemdup_noprof+0x34/0x60      [&lt;000000001176bb03&gt;] aa_unpack_strdup+0xd0/0x18c      [&lt;0000000046a45c1a&gt;] policy_unpack_test_unpack_strdup_with_name+0xd0/0x3c4      [&lt;0000000032ef8f77&gt;] kunit_try_run_case+0x13c/0x3ac      [&lt;00000000f3edea23&gt;] kunit_generic_run_threadfn_adapter+0x80/0xec      [&lt;00000000adf936cf&gt;] kthread+0x2e8/0x374      [&lt;0000000041bb1628&gt;] ret_from_fork+0x10/0x20(CVE-2024-56741)In the Linux kernel, the following vulnerability has been resolved:  scsi: qedi: Fix a possible memory leak in qedi_alloc_and_init_sb()  Hook &#34;qedi_ops-&gt;common-&gt;sb_init = qed_sb_init&#34; does not release the DMA memory sb_virt when it fails. Add dma_free_coherent() to free it. This is the same way as qedr_alloc_mem_sb() and qede_alloc_mem_sb().(CVE-2024-56747)In the Linux kernel, the following vulnerability has been resolved:  scsi: qedf: Fix a possible memory leak in qedf_alloc_and_init_sb()  Hook &#34;qed_ops-&gt;common-&gt;sb_init = qed_sb_init&#34; does not release the DMA memory sb_virt when it fails. Add dma_free_coherent() to free it. This is the same way as qedr_alloc_mem_sb() and qede_alloc_mem_sb().(CVE-2024-56748)In the Linux kernel, the following vulnerability has been resolved:  nvme-pci: fix freeing of the HMB descriptor table  The HMB descriptor table is sized to the maximum number of descriptors that could be used for a given device, but __nvme_alloc_host_mem could break out of the loop earlier on memory allocation failure and end up using less descriptors than planned for, which leads to an incorrect size passed to dma_free_coherent.  In practice this was not showing up because the number of descriptors tends to be low and the dma coherent allocator always allocates and frees at least a page.(CVE-2024-56756)In the Linux kernel, the following vulnerability has been resolved:  tracing: Prevent bad count for tracing_cpumask_write  If a large count is provided, it will trigger a warning in bitmap_parse_user. Also check zero for it.(CVE-2024-56763)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="bpftool" release="245.0.0.144.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-245.0.0.144.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="245.0.0.144.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-245.0.0.144.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="245.0.0.144.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-245.0.0.144.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="245.0.0.144.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-245.0.0.144.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="245.0.0.144.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-245.0.0.144.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="245.0.0.144.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-245.0.0.144.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="245.0.0.144.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-245.0.0.144.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="245.0.0.144.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-245.0.0.144.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="245.0.0.144.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-245.0.0.144.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="245.0.0.144.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-245.0.0.144.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="245.0.0.144.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-245.0.0.144.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="245.0.0.144.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-245.0.0.144.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="245.0.0.144.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-245.0.0.144.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="245.0.0.144.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-245.0.0.144.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="245.0.0.144.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-245.0.0.144.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="245.0.0.144.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-245.0.0.144.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="245.0.0.144.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-245.0.0.144.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="245.0.0.144.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-245.0.0.144.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="245.0.0.144.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-245.0.0.144.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="245.0.0.144.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-245.0.0.144.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="245.0.0.144.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-245.0.0.144.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="245.0.0.144.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-245.0.0.144.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="245.0.0.144.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-245.0.0.144.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="245.0.0.144.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-245.0.0.144.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="245.0.0.144.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-245.0.0.144.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="245.0.0.144.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-245.0.0.144.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="245.0.0.144.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-245.0.0.144.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="245.0.0.144.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-245.0.0.144.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="245.0.0.144.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-245.0.0.144.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="245.0.0.144.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-245.0.0.144.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1039</id>
          <title>An update for spark is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-01-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-23945" id="CVE-2024-23945" title="CVE-2024-23945" type="cve"></reference>
          </references>
          <description>Signing cookies is an application security feature that adds a digital signature to cookie data to verify its authenticity and integrity. The signature helps prevent malicious actors from modifying the cookie value, which can lead to security vulnerabilities and exploitation. Apache Hive’s service component accidentally exposes the signed cookie to the end user when there is a mismatch in signature between the current and expected cookie. Exposing the correct cookie signature can lead to further exploitation.  The vulnerable CookieSigner logic was introduced in Apache Hive by HIVE-9710 (1.2.0) and in Apache Spark by SPARK-14987 (2.0.0). The affected components are the following: * org.apache.hive:hive-service * org.apache.spark:spark-hive-thriftserver_2.11 * org.apache.spark:spark-hive-thriftserver_2.12(CVE-2024-23945)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="spark" release="3.oe2203sp4" version="3.2.2">
                         <filename>spark-3.2.2-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="spark" release="3.oe2203sp4" version="3.2.2">
                         <filename>spark-3.2.2-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1040</id>
          <title>An update for iperf3 is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-01-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53580" id="CVE-2024-53580" title="CVE-2024-53580" type="cve"></reference>
          </references>
          <description>iperf v3.17.1 was discovered to contain a segmentation violation via the iperf_exchange_parameters() function.(CVE-2024-53580)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="iperf3" release="1.oe2203sp4" version="3.18">
                         <filename>iperf3-3.18-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="iperf3-debuginfo" release="1.oe2203sp4" version="3.18">
                         <filename>iperf3-debuginfo-3.18-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="iperf3-debugsource" release="1.oe2203sp4" version="3.18">
                         <filename>iperf3-debugsource-3.18-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="iperf3-devel" release="1.oe2203sp4" version="3.18">
                         <filename>iperf3-devel-3.18-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="iperf3-help" release="1.oe2203sp4" version="3.18">
                         <filename>iperf3-help-3.18-1.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="iperf3" release="1.oe2203sp4" version="3.18">
                         <filename>iperf3-3.18-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="iperf3-debuginfo" release="1.oe2203sp4" version="3.18">
                         <filename>iperf3-debuginfo-3.18-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="iperf3-debugsource" release="1.oe2203sp4" version="3.18">
                         <filename>iperf3-debugsource-3.18-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="iperf3-devel" release="1.oe2203sp4" version="3.18">
                         <filename>iperf3-devel-3.18-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1041</id>
          <title>An update for perl-FCGI is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-01-17"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2012-6687" id="CVE-2012-6687" title="CVE-2012-6687" type="cve"></reference>
          </references>
          <description>(CVE-2012-6687)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="perl-FCGI" release="13.oe2203sp4" version="0.78">
                         <filename>perl-FCGI-0.78-13.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="perl-FCGI-debuginfo" release="13.oe2203sp4" version="0.78">
                         <filename>perl-FCGI-debuginfo-0.78-13.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="perl-FCGI-debugsource" release="13.oe2203sp4" version="0.78">
                         <filename>perl-FCGI-debugsource-0.78-13.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="perl-FCGI-help" release="13.oe2203sp4" version="0.78">
                         <filename>perl-FCGI-help-0.78-13.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="perl-FCGI" release="13.oe2203sp4" version="0.78">
                         <filename>perl-FCGI-0.78-13.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="perl-FCGI-debuginfo" release="13.oe2203sp4" version="0.78">
                         <filename>perl-FCGI-debuginfo-0.78-13.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="perl-FCGI-debugsource" release="13.oe2203sp4" version="0.78">
                         <filename>perl-FCGI-debugsource-0.78-13.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="perl-FCGI-help" release="13.oe2203sp4" version="0.78">
                         <filename>perl-FCGI-help-0.78-13.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1043</id>
          <title>An update for openjpeg2 is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-01-17"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56827" id="CVE-2024-56827" title="CVE-2024-56827" type="cve"></reference>
          </references>
          <description>(CVE-2024-56827)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="openjpeg2" release="6.oe2203sp4" version="2.5.0">
                         <filename>openjpeg2-2.5.0-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openjpeg2-debuginfo" release="6.oe2203sp4" version="2.5.0">
                         <filename>openjpeg2-debuginfo-2.5.0-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openjpeg2-debugsource" release="6.oe2203sp4" version="2.5.0">
                         <filename>openjpeg2-debugsource-2.5.0-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openjpeg2-devel" release="6.oe2203sp4" version="2.5.0">
                         <filename>openjpeg2-devel-2.5.0-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openjpeg2-tools" release="6.oe2203sp4" version="2.5.0">
                         <filename>openjpeg2-tools-2.5.0-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="openjpeg2-help" release="6.oe2203sp4" version="2.5.0">
                         <filename>openjpeg2-help-2.5.0-6.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openjpeg2" release="6.oe2203sp4" version="2.5.0">
                         <filename>openjpeg2-2.5.0-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openjpeg2-debuginfo" release="6.oe2203sp4" version="2.5.0">
                         <filename>openjpeg2-debuginfo-2.5.0-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openjpeg2-debugsource" release="6.oe2203sp4" version="2.5.0">
                         <filename>openjpeg2-debugsource-2.5.0-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openjpeg2-devel" release="6.oe2203sp4" version="2.5.0">
                         <filename>openjpeg2-devel-2.5.0-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openjpeg2-tools" release="6.oe2203sp4" version="2.5.0">
                         <filename>openjpeg2-tools-2.5.0-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1044</id>
          <title>An update for apache-mina is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-01-17"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-52046" id="CVE-2024-52046" title="CVE-2024-52046" type="cve"></reference>
          </references>
          <description>The ObjectSerializationDecoder in Apache MINA uses Java’s native deserialization protocol to process incoming serialized data but lacks the necessary security checks and defenses. This vulnerability allows attackers to exploit the deserialization process by sending specially crafted malicious serialized data, potentially leading to remote code execution (RCE) attacks.                                This issue affects MINA core versions 2.0.X, 2.1.X and 2.2.X, and will be fixed by the releases 2.0.27, 2.1.10 and 2.2.4.      It&#39;s also important to note that an application using MINA core library will only be affected if the IoBuffer#getObject() method is called, and this specific method is potentially called when adding a ProtocolCodecFilter instance using the ObjectSerializationCodecFactory class in the filter chain. If your application is specifically using those classes, you have to upgrade to the latest version of MINA core library.     Upgrading will  not be enough: you also need to explicitly allow the classes the decoder will accept in the ObjectSerializationDecoder instance, using one of the three new methods:         /**       * Accept class names where the supplied ClassNameMatcher matches for       * deserialization, unless they are otherwise rejected.       *       * @param classNameMatcher the matcher to use       */      public void accept(ClassNameMatcher classNameMatcher)         /**       * Accept class names that match the supplied pattern for       * deserialization, unless they are otherwise rejected.       *       * @param pattern standard Java regexp       */      public void accept(Pattern pattern)           /**       * Accept the wildcard specified classes for deserialization,       * unless they are otherwise rejected.       *       * @param patterns Wildcard file name patterns as defined by       *                  {@link org.apache.commons.io.FilenameUtils#wildcardMatch(String, String) FilenameUtils.wildcardMatch}       */      public void accept(String... patterns)        By default, the decoder will reject *all* classes that will be present in the incoming data.        Note: The FtpServer, SSHd and Vysper sub-project are not affected by this issue.(CVE-2024-52046)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="apache-mina" release="1.oe2203sp4" version="2.0.27">
                         <filename>apache-mina-2.0.27-1.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="apache-mina-javadoc" release="1.oe2203sp4" version="2.0.27">
                         <filename>apache-mina-javadoc-2.0.27-1.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="apache-mina-mina-core" release="1.oe2203sp4" version="2.0.27">
                         <filename>apache-mina-mina-core-2.0.27-1.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="apache-mina-mina-filter-compression" release="1.oe2203sp4" version="2.0.27">
                         <filename>apache-mina-mina-filter-compression-2.0.27-1.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="apache-mina-mina-http" release="1.oe2203sp4" version="2.0.27">
                         <filename>apache-mina-mina-http-2.0.27-1.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="apache-mina-mina-statemachine" release="1.oe2203sp4" version="2.0.27">
                         <filename>apache-mina-mina-statemachine-2.0.27-1.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1048</id>
          <title>An update for python-aiohttp is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-01-17"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-52304" id="CVE-2024-52304" title="CVE-2024-52304" type="cve"></reference>
          </references>
          <description>aiohttp is an asynchronous HTTP client/server framework for asyncio and Python. Prior to version 3.10.11, the Python parser parses newlines in chunk extensions incorrectly which can lead to request smuggling vulnerabilities under certain conditions. If a pure Python version of aiohttp is installed (i.e. without the usual C extensions) or `AIOHTTP_NO_EXTENSIONS` is enabled, then an attacker may be able to execute a request smuggling attack to bypass certain firewalls or proxy protections. Version 3.10.11 fixes the issue.(CVE-2024-52304)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="python-aiohttp-debuginfo" release="5.oe2203sp4" version="3.7.4">
                         <filename>python-aiohttp-debuginfo-3.7.4-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python-aiohttp-debugsource" release="5.oe2203sp4" version="3.7.4">
                         <filename>python-aiohttp-debugsource-3.7.4-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python-aiohttp-help" release="5.oe2203sp4" version="3.7.4">
                         <filename>python-aiohttp-help-3.7.4-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-aiohttp" release="5.oe2203sp4" version="3.7.4">
                         <filename>python3-aiohttp-3.7.4-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python-aiohttp-debuginfo" release="5.oe2203sp4" version="3.7.4">
                         <filename>python-aiohttp-debuginfo-3.7.4-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python-aiohttp-debugsource" release="5.oe2203sp4" version="3.7.4">
                         <filename>python-aiohttp-debugsource-3.7.4-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python-aiohttp-help" release="5.oe2203sp4" version="3.7.4">
                         <filename>python-aiohttp-help-3.7.4-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-aiohttp" release="5.oe2203sp4" version="3.7.4">
                         <filename>python3-aiohttp-3.7.4-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1051</id>
          <title>An update for enscript is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-01-17"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2018-17942" id="CVE-2018-17942" title="CVE-2018-17942" type="cve"></reference>
          </references>
          <description>(CVE-2018-17942)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="enscript" release="22.oe2203sp4" version="1.6.6">
                         <filename>enscript-1.6.6-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="enscript-debuginfo" release="22.oe2203sp4" version="1.6.6">
                         <filename>enscript-debuginfo-1.6.6-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="enscript-debugsource" release="22.oe2203sp4" version="1.6.6">
                         <filename>enscript-debugsource-1.6.6-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="enscript-help" release="22.oe2203sp4" version="1.6.6">
                         <filename>enscript-help-1.6.6-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="enscript" release="22.oe2203sp4" version="1.6.6">
                         <filename>enscript-1.6.6-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="enscript-debuginfo" release="22.oe2203sp4" version="1.6.6">
                         <filename>enscript-debuginfo-1.6.6-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="enscript-debugsource" release="22.oe2203sp4" version="1.6.6">
                         <filename>enscript-debugsource-1.6.6-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="enscript-help" release="22.oe2203sp4" version="1.6.6">
                         <filename>enscript-help-1.6.6-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1054</id>
          <title>An update for podman is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-01-17"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2019-9514" id="CVE-2019-9514" title="CVE-2019-9514" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-1962" id="CVE-2022-1962" title="CVE-2022-1962" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-2880" id="CVE-2022-2880" title="CVE-2022-2880" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-32189" id="CVE-2022-32189" title="CVE-2022-32189" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41715" id="CVE-2022-41715" title="CVE-2022-41715" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24791" id="CVE-2024-24791" title="CVE-2024-24791" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-37298" id="CVE-2024-37298" title="CVE-2024-37298" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-9355" id="CVE-2024-9355" title="CVE-2024-9355" type="cve"></reference>
          </references>
          <description>Some HTTP/2 implementations are vulnerable to a reset flood, potentially leading to a denial of service. The attacker opens a number of streams and sends an invalid request over each stream that should solicit a stream of RST_STREAM frames from the peer. Depending on how the peer queues the RST_STREAM frames, this can consume excess memory, CPU, or both.(CVE-2019-9514)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)Requests forwarded by ReverseProxy include the raw query parameters from the inbound request, including unparsable parameters rejected by net/http. This could permit query parameter smuggling when a Go proxy forwards a parameter with an unparsable value. After fix, ReverseProxy sanitizes the query parameters in the forwarded query when the outbound request&#39;s Form field is set after the ReverseProxy. Director function returns, indicating that the proxy has parsed the query parameters. Proxies which do not parse query parameters continue to forward the original query parameters unchanged.(CVE-2022-2880)A too-short encoded message can cause a panic in Float.GobDecode and Rat GobDecode in math/big in Go before 1.17.13 and 1.18.5, potentially allowing a denial of service.(CVE-2022-32189)Programs which compile regular expressions from untrusted sources may be vulnerable to memory exhaustion or denial of service. The parsed regexp representation is linear in the size of the input, but in some cases the constant factor can be as high as 40,000, making relatively small regexps consume much larger amounts of memory. After fix, each regexp being parsed is limited to a 256 MB memory footprint. Regular expressions whose representation would use more space than that are rejected. Normal use of regular expressions is unaffected.(CVE-2022-41715)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)gorilla/schema converts structs to and from form values. Prior to version 1.4.1 Running `schema.Decoder.Decode()` on a struct that has a field of type `[]struct{...}` opens it up to malicious attacks regarding memory allocations, taking advantage of the sparse slice functionality. Any use of `schema.Decoder.Decode()` on a struct with arrays of other structs could be vulnerable to this memory exhaustion vulnerability. Version 1.4.1 contains a patch for the issue.(CVE-2024-37298)A vulnerability was found in Golang FIPS OpenSSL. This flaw allows a malicious user to randomly cause an uninitialized buffer length variable with a zeroed buffer to be returned in FIPS mode. It may also be possible to force a false positive match between non-equal hashes when comparing a trusted computed hmac sum to an untrusted input sum if an attacker can send a zeroed buffer in place of a pre-computed sum.  It is also possible to force a derived key to be all zeros instead of an unpredictable value.  This may have follow-on implications for the Go TLS stack.(CVE-2024-9355)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="podman" release="5.oe2203sp4" version="3.4.4">
                         <filename>podman-3.4.4-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="podman-debuginfo" release="5.oe2203sp4" version="3.4.4">
                         <filename>podman-debuginfo-3.4.4-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="podman-debugsource" release="5.oe2203sp4" version="3.4.4">
                         <filename>podman-debugsource-3.4.4-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="podman-gvproxy" release="5.oe2203sp4" version="3.4.4">
                         <filename>podman-gvproxy-3.4.4-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="podman-plugins" release="5.oe2203sp4" version="3.4.4">
                         <filename>podman-plugins-3.4.4-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="podman-remote" release="5.oe2203sp4" version="3.4.4">
                         <filename>podman-remote-3.4.4-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="podman-docker" release="5.oe2203sp4" version="3.4.4">
                         <filename>podman-docker-3.4.4-5.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="podman-help" release="5.oe2203sp4" version="3.4.4">
                         <filename>podman-help-3.4.4-5.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="podman" release="5.oe2203sp4" version="3.4.4">
                         <filename>podman-3.4.4-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="podman-debuginfo" release="5.oe2203sp4" version="3.4.4">
                         <filename>podman-debuginfo-3.4.4-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="podman-debugsource" release="5.oe2203sp4" version="3.4.4">
                         <filename>podman-debugsource-3.4.4-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="podman-gvproxy" release="5.oe2203sp4" version="3.4.4">
                         <filename>podman-gvproxy-3.4.4-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="podman-plugins" release="5.oe2203sp4" version="3.4.4">
                         <filename>podman-plugins-3.4.4-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="podman-remote" release="5.oe2203sp4" version="3.4.4">
                         <filename>podman-remote-3.4.4-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1059</id>
          <title>An update for buildah is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2025-01-17"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-34558" id="CVE-2021-34558" title="CVE-2021-34558" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-1962" id="CVE-2022-1962" title="CVE-2022-1962" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-2990" id="CVE-2022-2990" title="CVE-2022-2990" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41715" id="CVE-2022-41715" title="CVE-2022-41715" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41723" id="CVE-2022-41723" title="CVE-2022-41723" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-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>
               <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>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1753" id="CVE-2024-1753" title="CVE-2024-1753" type="cve"></reference>
               <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 crypto/tls package of Go through 1.16.5 does not properly assert that the type of public key in an X.509 certificate matches the expected type when doing a RSA based key exchange, allowing a malicious TLS server to cause a TLS client to panic.(CVE-2021-34558)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)An incorrect handling of the supplementary groups in the Buildah container engine might lead to the sensitive information disclosure or possible data modification if an attacker has direct access to the affected container where supplementary groups are used to set access permissions and is able to execute a binary code in that container.(CVE-2022-2990)Programs which compile regular expressions from untrusted sources may be vulnerable to memory exhaustion or denial of service. The parsed regexp representation is linear in the size of the input, but in some cases the constant factor can be as high as 40,000, making relatively small regexps consume much larger amounts of memory. After fix, each regexp being parsed is limited to a 256 MB memory footprint. Regular expressions whose representation would use more space than that are rejected. Normal use of regular expressions is unaffected.(CVE-2022-41715)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)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)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)A flaw was found in Buildah (and subsequently Podman Build) which allows containers to mount arbitrary locations on the host filesystem into build containers. A malicious Containerfile can use a dummy image with a symbolic link to the root filesystem as a mount source and cause the mount operation to mount the host root filesystem inside the RUN step. The commands inside the RUN step will then have read-write access to the host filesystem, allowing for full container escape at build time.(CVE-2024-1753)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="buildah" release="4.oe2203sp4" version="1.26.1">
                         <filename>buildah-1.26.1-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="buildah-debuginfo" release="4.oe2203sp4" version="1.26.1">
                         <filename>buildah-debuginfo-1.26.1-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="buildah-debugsource" release="4.oe2203sp4" version="1.26.1">
                         <filename>buildah-debugsource-1.26.1-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="buildah" release="4.oe2203sp4" version="1.26.1">
                         <filename>buildah-1.26.1-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="buildah-debuginfo" release="4.oe2203sp4" version="1.26.1">
                         <filename>buildah-debuginfo-1.26.1-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="buildah-debugsource" release="4.oe2203sp4" version="1.26.1">
                         <filename>buildah-debugsource-1.26.1-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1060</id>
          <title>An update for rsync is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-01-17"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-12085" id="CVE-2024-12085" title="CVE-2024-12085" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-12086" id="CVE-2024-12086" title="CVE-2024-12086" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-12087" id="CVE-2024-12087" title="CVE-2024-12087" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-12088" id="CVE-2024-12088" title="CVE-2024-12088" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-12747" id="CVE-2024-12747" title="CVE-2024-12747" type="cve"></reference>
          </references>
          <description>(CVE-2024-12085)(CVE-2024-12086)(CVE-2024-12087)(CVE-2024-12088)(CVE-2024-12747)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="rsync" release="4.oe2203sp4" version="3.2.5">
                         <filename>rsync-3.2.5-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rsync-debuginfo" release="4.oe2203sp4" version="3.2.5">
                         <filename>rsync-debuginfo-3.2.5-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rsync-debugsource" release="4.oe2203sp4" version="3.2.5">
                         <filename>rsync-debugsource-3.2.5-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="rsync-help" release="4.oe2203sp4" version="3.2.5">
                         <filename>rsync-help-3.2.5-4.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rsync" release="4.oe2203sp4" version="3.2.5">
                         <filename>rsync-3.2.5-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rsync-debuginfo" release="4.oe2203sp4" version="3.2.5">
                         <filename>rsync-debuginfo-3.2.5-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rsync-debugsource" release="4.oe2203sp4" version="3.2.5">
                         <filename>rsync-debugsource-3.2.5-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1065</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-01-17"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50199" id="CVE-2024-50199" title="CVE-2024-50199" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53171" id="CVE-2024-53171" title="CVE-2024-53171" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53190" id="CVE-2024-53190" title="CVE-2024-53190" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53237" id="CVE-2024-53237" title="CVE-2024-53237" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53239" id="CVE-2024-53239" title="CVE-2024-53239" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56567" id="CVE-2024-56567" title="CVE-2024-56567" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56595" id="CVE-2024-56595" title="CVE-2024-56595" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56597" id="CVE-2024-56597" title="CVE-2024-56597" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56631" id="CVE-2024-56631" title="CVE-2024-56631" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56633" id="CVE-2024-56633" title="CVE-2024-56633" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56662" id="CVE-2024-56662" title="CVE-2024-56662" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56701" id="CVE-2024-56701" title="CVE-2024-56701" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56759" id="CVE-2024-56759" title="CVE-2024-56759" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:  mm/swapfile: skip HugeTLB pages for unuse_vma  I got a bad pud error and lost a 1GB HugeTLB when calling swapoff.  The problem can be reproduced by the following steps:   1. Allocate an anonymous 1GB HugeTLB and some other anonymous memory.  2. Swapout the above anonymous memory.  3. run swapoff and we will get a bad pud error in kernel message:    mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7)  We can tell that pud_clear_bad is called by pud_none_or_clear_bad in unuse_pud_range() by ftrace.  And therefore the HugeTLB pages will never be freed because we lost it from page table.  We can skip HugeTLB pages for unuse_vma to fix it.(CVE-2024-50199)In the Linux kernel, the following vulnerability has been resolved:  ubifs: authentication: Fix use-after-free in ubifs_tnc_end_commit  After an insertion in TNC, the tree might split and cause a node to change its `znode-&gt;parent`. A further deletion of other nodes in the tree (which also could free the nodes), the aforementioned node&#39;s `znode-&gt;cparent` could still point to a freed node. This `znode-&gt;cparent` may not be updated when getting nodes to commit in `ubifs_tnc_start_commit()`. This could then trigger a use-after-free when accessing the `znode-&gt;cparent` in `write_index()` in `ubifs_tnc_end_commit()`.  This can be triggered by running    rm -f /etc/test-file.bin   dd if=/dev/urandom of=/etc/test-file.bin bs=1M count=60 conv=fsync  in a loop, and with `CONFIG_UBIFS_FS_AUTHENTICATION`. KASAN then reports:    BUG: KASAN: use-after-free in ubifs_tnc_end_commit+0xa5c/0x1950   Write of size 32 at addr ffffff800a3af86c by task ubifs_bgt0_20/153    Call trace:    dump_backtrace+0x0/0x340    show_stack+0x18/0x24    dump_stack_lvl+0x9c/0xbc    print_address_description.constprop.0+0x74/0x2b0    kasan_report+0x1d8/0x1f0    kasan_check_range+0xf8/0x1a0    memcpy+0x84/0xf4    ubifs_tnc_end_commit+0xa5c/0x1950    do_commit+0x4e0/0x1340    ubifs_bg_thread+0x234/0x2e0    kthread+0x36c/0x410    ret_from_fork+0x10/0x20    Allocated by task 401:    kasan_save_stack+0x38/0x70    __kasan_kmalloc+0x8c/0xd0    __kmalloc+0x34c/0x5bc    tnc_insert+0x140/0x16a4    ubifs_tnc_add+0x370/0x52c    ubifs_jnl_write_data+0x5d8/0x870    do_writepage+0x36c/0x510    ubifs_writepage+0x190/0x4dc    __writepage+0x58/0x154    write_cache_pages+0x394/0x830    do_writepages+0x1f0/0x5b0    filemap_fdatawrite_wbc+0x170/0x25c    file_write_and_wait_range+0x140/0x190    ubifs_fsync+0xe8/0x290    vfs_fsync_range+0xc0/0x1e4    do_fsync+0x40/0x90    __arm64_sys_fsync+0x34/0x50    invoke_syscall.constprop.0+0xa8/0x260    do_el0_svc+0xc8/0x1f0    el0_svc+0x34/0x70    el0t_64_sync_handler+0x108/0x114    el0t_64_sync+0x1a4/0x1a8    Freed by task 403:    kasan_save_stack+0x38/0x70    kasan_set_track+0x28/0x40    kasan_set_free_info+0x28/0x4c    __kasan_slab_free+0xd4/0x13c    kfree+0xc4/0x3a0    tnc_delete+0x3f4/0xe40    ubifs_tnc_remove_range+0x368/0x73c    ubifs_tnc_remove_ino+0x29c/0x2e0    ubifs_jnl_delete_inode+0x150/0x260    ubifs_evict_inode+0x1d4/0x2e4    evict+0x1c8/0x450    iput+0x2a0/0x3c4    do_unlinkat+0x2cc/0x490    __arm64_sys_unlinkat+0x90/0x100    invoke_syscall.constprop.0+0xa8/0x260    do_el0_svc+0xc8/0x1f0    el0_svc+0x34/0x70    el0t_64_sync_handler+0x108/0x114    el0t_64_sync+0x1a4/0x1a8  The offending `memcpy()` in `ubifs_copy_hash()` has a use-after-free when a node becomes root in TNC but still has a `cparent` to an already freed node. More specifically, consider the following TNC:           zroot          /         /       zp1       /      /     zn  Inserting a new node `zn_new` with a key smaller then `zn` will trigger a split in `tnc_insert()` if `zp1` is full:           zroot          /   \         /     \       zp1     zp2       /         \      /           \   zn_new          zn  `zn-&gt;parent` has now been moved to `zp2`, *but* `zn-&gt;cparent` still points to `zp1`.  Now, consider a removal of all the nodes _except_ `zn`. Just when `tnc_delete()` is about to delete `zroot` and `zp2`:           zroot              \               \               zp2                 \                  \                  zn  `zroot` and `zp2` get freed and the tree collapses:             zn  `zn` now becomes the new `zroot`.  `get_znodes_to_commit()` will now only find `zn`, the new `zroot`, and `write_index()` will check its `znode-&gt;cparent` that wrongly points to the already freed `zp1`. `ubifs_copy_hash()` thus gets wrongly called with `znode-&gt;cparent-&gt;zbranch[znode-&gt;iip].hash` that triggers the use-after-free!  Fix this by explicitly setting `znode-&gt;cparent` to `NULL` in `get_znodes_to_commit()` for the root node. The search for the dirty nodes ---truncated---(CVE-2024-53171)In the Linux kernel, the following vulnerability has been resolved:  wifi: rtlwifi: Drastically reduce the attempts to read efuse in case of failures  Syzkaller reported a hung task with uevent_show() on stack trace. That specific issue was addressed by another commit [0], but even with that fix applied (for example, running v6.12-rc5) we face another type of hung task that comes from the same reproducer [1]. By investigating that, we could narrow it to the following path:  (a) Syzkaller emulates a Realtek USB WiFi adapter using raw-gadget and dummy_hcd infrastructure.  (b) During the probe of rtl8192cu, the driver ends-up performing an efuse read procedure (which is related to EEPROM load IIUC), and here lies the issue: the function read_efuse() calls read_efuse_byte() many times, as loop iterations depending on the efuse size (in our example, 512 in total).  This procedure for reading efuse bytes relies in a loop that performs an I/O read up to *10k* times in case of failures. We measured the time of the loop inside read_efuse_byte() alone, and in this reproducer (which involves the dummy_hcd emulation layer), it takes 15 seconds each. As a consequence, we have the driver stuck in its probe routine for big time, exposing a stack trace like below if we attempt to reboot the system, for example:  task:kworker/0:3 state:D stack:0 pid:662 tgid:662 ppid:2 flags:0x00004000 Workqueue: usb_hub_wq hub_event Call Trace:  __schedule+0xe22/0xeb6  schedule_timeout+0xe7/0x132  __wait_for_common+0xb5/0x12e  usb_start_wait_urb+0xc5/0x1ef  ? usb_alloc_urb+0x95/0xa4  usb_control_msg+0xff/0x184  _usbctrl_vendorreq_sync+0xa0/0x161  _usb_read_sync+0xb3/0xc5  read_efuse_byte+0x13c/0x146  read_efuse+0x351/0x5f0  efuse_read_all_map+0x42/0x52  rtl_efuse_shadow_map_update+0x60/0xef  rtl_get_hwinfo+0x5d/0x1c2  rtl92cu_read_eeprom_info+0x10a/0x8d5  ? rtl92c_read_chip_version+0x14f/0x17e  rtl_usb_probe+0x323/0x851  usb_probe_interface+0x278/0x34b  really_probe+0x202/0x4a4  __driver_probe_device+0x166/0x1b2  driver_probe_device+0x2f/0xd8  [...]  We propose hereby to drastically reduce the attempts of doing the I/O reads in case of failures, restricted to USB devices (given that they&#39;re inherently slower than PCIe ones). By retrying up to 10 times (instead of 10000), we got reponsiveness in the reproducer, while seems reasonable to believe that there&#39;s no sane USB device implementation in the field requiring this amount of retries at every I/O read in order to properly work. Based on that assumption, it&#39;d be good to have it backported to stable but maybe not since driver implementation (the 10k number comes from day 0), perhaps up to 6.x series makes sense.  [0] Commit 15fffc6a5624 (&#34;driver core: Fix uevent_show() vs driver detach race&#34;)  [1] A note about that: this syzkaller report presents multiple reproducers that differs by the type of emulated USB device. For this specific case, check the entry from 2024/08/08 06:23 in the list of crashes; the C repro is available at https://syzkaller.appspot.com/text?tag=ReproC&amp;x=1521fc83980000.(CVE-2024-53190)In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: fix use-after-free in device_for_each_child()  Syzbot has reported the following KASAN splat:  BUG: KASAN: slab-use-after-free in device_for_each_child+0x18f/0x1a0 Read of size 8 at addr ffff88801f605308 by task kbnepd bnep0/4980  CPU: 0 UID: 0 PID: 4980 Comm: kbnepd bnep0 Not tainted 6.12.0-rc4-00161-gae90f6a6170d #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 Call Trace:  &lt;TASK&gt;  dump_stack_lvl+0x100/0x190  ? device_for_each_child+0x18f/0x1a0  print_report+0x13a/0x4cb  ? __virt_addr_valid+0x5e/0x590  ? __phys_addr+0xc6/0x150  ? device_for_each_child+0x18f/0x1a0  kasan_report+0xda/0x110  ? device_for_each_child+0x18f/0x1a0  ? __pfx_dev_memalloc_noio+0x10/0x10  device_for_each_child+0x18f/0x1a0  ? __pfx_device_for_each_child+0x10/0x10  pm_runtime_set_memalloc_noio+0xf2/0x180  netdev_unregister_kobject+0x1ed/0x270  unregister_netdevice_many_notify+0x123c/0x1d80  ? __mutex_trylock_common+0xde/0x250  ? __pfx_unregister_netdevice_many_notify+0x10/0x10  ? trace_contention_end+0xe6/0x140  ? __mutex_lock+0x4e7/0x8f0  ? __pfx_lock_acquire.part.0+0x10/0x10  ? rcu_is_watching+0x12/0xc0  ? unregister_netdev+0x12/0x30  unregister_netdevice_queue+0x30d/0x3f0  ? __pfx_unregister_netdevice_queue+0x10/0x10  ? __pfx_down_write+0x10/0x10  unregister_netdev+0x1c/0x30  bnep_session+0x1fb3/0x2ab0  ? __pfx_bnep_session+0x10/0x10  ? __pfx_lock_release+0x10/0x10  ? __pfx_woken_wake_function+0x10/0x10  ? __kthread_parkme+0x132/0x200  ? __pfx_bnep_session+0x10/0x10  ? kthread+0x13a/0x370  ? __pfx_bnep_session+0x10/0x10  kthread+0x2b7/0x370  ? __pfx_kthread+0x10/0x10  ret_from_fork+0x48/0x80  ? __pfx_kthread+0x10/0x10  ret_from_fork_asm+0x1a/0x30  &lt;/TASK&gt;  Allocated by task 4974:  kasan_save_stack+0x30/0x50  kasan_save_track+0x14/0x30  __kasan_kmalloc+0xaa/0xb0  __kmalloc_noprof+0x1d1/0x440  hci_alloc_dev_priv+0x1d/0x2820  __vhci_create_device+0xef/0x7d0  vhci_write+0x2c7/0x480  vfs_write+0x6a0/0xfc0  ksys_write+0x12f/0x260  do_syscall_64+0xc7/0x250  entry_SYSCALL_64_after_hwframe+0x77/0x7f  Freed by task 4979:  kasan_save_stack+0x30/0x50  kasan_save_track+0x14/0x30  kasan_save_free_info+0x3b/0x60  __kasan_slab_free+0x4f/0x70  kfree+0x141/0x490  hci_release_dev+0x4d9/0x600  bt_host_release+0x6a/0xb0  device_release+0xa4/0x240  kobject_put+0x1ec/0x5a0  put_device+0x1f/0x30  vhci_release+0x81/0xf0  __fput+0x3f6/0xb30  task_work_run+0x151/0x250  do_exit+0xa79/0x2c30  do_group_exit+0xd5/0x2a0  get_signal+0x1fcd/0x2210  arch_do_signal_or_restart+0x93/0x780  syscall_exit_to_user_mode+0x140/0x290  do_syscall_64+0xd4/0x250  entry_SYSCALL_64_after_hwframe+0x77/0x7f  In &#39;hci_conn_del_sysfs()&#39;, &#39;device_unregister()&#39; may be called when an underlying (kobject) reference counter is greater than 1. This means that reparenting (happened when the device is actually freed) is delayed and, during that delay, parent controller device (hciX) may be deleted. Since the latter may create a dangling pointer to freed parent, avoid that scenario by reparenting to NULL explicitly.(CVE-2024-53237)In the Linux kernel, the following vulnerability has been resolved:  ALSA: 6fire: Release resources at card release  The current 6fire code tries to release the resources right after the call of usb6fire_chip_abort().  But at this moment, the card object might be still in use (as we&#39;re calling snd_card_free_when_closed()).  For avoid potential UAFs, move the release of resources to the card&#39;s private_free instead of the manual call of usb6fire_chip_destroy() at the USB disconnect callback.(CVE-2024-53239)In the Linux kernel, the following vulnerability has been resolved:  ad7780: fix division by zero in ad7780_write_raw()  In the ad7780_write_raw() , val2 can be zero, which might lead to a division by zero error in DIV_ROUND_CLOSEST(). The ad7780_write_raw() is based on iio_info&#39;s write_raw. While val is explicitly declared that can be zero (in read mode), val2 is not specified to be non-zero.(CVE-2024-56567)In the Linux kernel, the following vulnerability has been resolved:  jfs: add a check to prevent array-index-out-of-bounds in dbAdjTree  When the value of lp is 0 at the beginning of the for loop, it will become negative in the next assignment and we should bail out.(CVE-2024-56595)In the Linux kernel, the following vulnerability has been resolved:  jfs: fix shift-out-of-bounds in dbSplit  When dmt_budmin is less than zero, it causes errors in the later stages. Added a check to return an error beforehand in dbAllocCtl itself.(CVE-2024-56597)In the Linux kernel, the following vulnerability has been resolved:  scsi: sg: Fix slab-use-after-free read in sg_release()  Fix a use-after-free bug in sg_release(), detected by syzbot with KASAN:  BUG: KASAN: slab-use-after-free in lock_release+0x151/0xa30 kernel/locking/lockdep.c:5838 __mutex_unlock_slowpath+0xe2/0x750 kernel/locking/mutex.c:912 sg_release+0x1f4/0x2e0 drivers/scsi/sg.c:407  In sg_release(), the function kref_put(&amp;sfp-&gt;f_ref, sg_remove_sfp) is called before releasing the open_rel_lock mutex. The kref_put() call may decrement the reference count of sfp to zero, triggering its cleanup through sg_remove_sfp(). This cleanup includes scheduling deferred work via sg_remove_sfp_usercontext(), which ultimately frees sfp.  After kref_put(), sg_release() continues to unlock open_rel_lock and may reference sfp or sdp. If sfp has already been freed, this results in a slab-use-after-free error.  Move the kref_put(&amp;sfp-&gt;f_ref, sg_remove_sfp) call after unlocking the open_rel_lock mutex. This ensures:   - No references to sfp or sdp occur after the reference count is    decremented.   - Cleanup functions such as sg_remove_sfp() and    sg_remove_sfp_usercontext() can safely execute without impacting the    mutex handling in sg_release().  The fix has been tested and validated by syzbot. This patch closes the bug reported at the following syzkaller link and ensures proper sequencing of resource cleanup and mutex operations, eliminating the risk of use-after-free errors in sg_release().(CVE-2024-56631)In the Linux kernel, the following vulnerability has been resolved:  tcp_bpf: Fix the sk_mem_uncharge logic in tcp_bpf_sendmsg  The current sk memory accounting logic in __SK_REDIRECT is pre-uncharging tosend bytes, which is either msg-&gt;sg.size or a smaller value apply_bytes.  Potential problems with this strategy are as follows:  - If the actual sent bytes are smaller than tosend, we need to charge some   bytes back, as in line 487, which is okay but seems not clean.  - When tosend is set to apply_bytes, as in line 417, and (ret &lt; 0), we may   miss uncharging (msg-&gt;sg.size - apply_bytes) bytes.  [...] 415 tosend = msg-&gt;sg.size; 416 if (psock-&gt;apply_bytes &amp;&amp; psock-&gt;apply_bytes &lt; tosend) 417   tosend = psock-&gt;apply_bytes; [...] 443 sk_msg_return(sk, msg, tosend); 444 release_sock(sk); 446 origsize = msg-&gt;sg.size; 447 ret = tcp_bpf_sendmsg_redir(sk_redir, redir_ingress, 448                             msg, tosend, flags); 449 sent = origsize - msg-&gt;sg.size; [...] 454 lock_sock(sk); 455 if (unlikely(ret &lt; 0)) { 456   int free = sk_msg_free_nocharge(sk, msg); 458   if (!cork) 459     *copied -= free; 460 } [...] 487 if (eval == __SK_REDIRECT) 488   sk_mem_charge(sk, tosend - sent); [...]  When running the selftest test_txmsg_redir_wait_sndmem with txmsg_apply, the following warning will be reported:  ------------[ cut here ]------------ WARNING: CPU: 6 PID: 57 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x190/0x1a0 Modules linked in: CPU: 6 UID: 0 PID: 57 Comm: kworker/6:0 Not tainted 6.12.0-rc1.bm.1-amd64+ #43 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 Workqueue: events sk_psock_destroy RIP: 0010:inet_sock_destruct+0x190/0x1a0 RSP: 0018:ffffad0a8021fe08 EFLAGS: 00010206 RAX: 0000000000000011 RBX: ffff9aab4475b900 RCX: ffff9aab481a0800 RDX: 0000000000000303 RSI: 0000000000000011 RDI: ffff9aab4475b900 RBP: ffff9aab4475b990 R08: 0000000000000000 R09: ffff9aab40050ec0 R10: 0000000000000000 R11: ffff9aae6fdb1d01 R12: ffff9aab49c60400 R13: ffff9aab49c60598 R14: ffff9aab49c60598 R15: dead000000000100 FS:  0000000000000000(0000) GS:ffff9aae6fd80000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffec7e47bd8 CR3: 00000001a1a1c004 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: &lt;TASK&gt; ? __warn+0x89/0x130 ? inet_sock_destruct+0x190/0x1a0 ? report_bug+0xfc/0x1e0 ? handle_bug+0x5c/0xa0 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? inet_sock_destruct+0x190/0x1a0 __sk_destruct+0x25/0x220 sk_psock_destroy+0x2b2/0x310 process_scheduled_works+0xa3/0x3e0 worker_thread+0x117/0x240 ? __pfx_worker_thread+0x10/0x10 kthread+0xcf/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 &lt;/TASK&gt; ---[ end trace 0000000000000000 ]---  In __SK_REDIRECT, a more concise way is delaying the uncharging after sent bytes are finalized, and uncharge this value. When (ret &lt; 0), we shall invoke sk_msg_free.  Same thing happens in case __SK_DROP, when tosend is set to apply_bytes, we may miss uncharging (msg-&gt;sg.size - apply_bytes) bytes. The same warning will be reported in selftest.  [...] 468 case __SK_DROP: 469 default: 470 sk_msg_free_partial(sk, msg, tosend); 471 sk_msg_apply_bytes(psock, tosend); 472 *copied -= (tosend + delta); 473 return -EACCES; [...]  So instead of sk_msg_free_partial we can do sk_msg_free here.(CVE-2024-56633)In the Linux kernel, the following vulnerability has been resolved:  acpi: nfit: vmalloc-out-of-bounds Read in acpi_nfit_ctl  Fix an issue detected by syzbot with KASAN:  BUG: KASAN: vmalloc-out-of-bounds in cmd_to_func drivers/acpi/nfit/ core.c:416 [inline] BUG: KASAN: vmalloc-out-of-bounds in acpi_nfit_ctl+0x20e8/0x24a0 drivers/acpi/nfit/core.c:459  The issue occurs in cmd_to_func when the call_pkg-&gt;nd_reserved2 array is accessed without verifying that call_pkg points to a buffer that is appropriately sized as a struct nd_cmd_pkg. This can lead to out-of-bounds access and undefined behavior if the buffer does not have sufficient space.  To address this, a check was added in acpi_nfit_ctl() to ensure that buf is not NULL and that buf_len is less than sizeof(*call_pkg) before accessing it. This ensures safe access to the members of call_pkg, including the nd_reserved2 array.(CVE-2024-56662)In the Linux kernel, the following vulnerability has been resolved:  powerpc/pseries: Fix dtl_access_lock to be a rw_semaphore  The dtl_access_lock needs to be a rw_sempahore, a sleeping lock, because the code calls kmalloc() while holding it, which can sleep:    # echo 1 &gt; /proc/powerpc/vcpudispatch_stats   BUG: sleeping function called from invalid context at include/linux/sched/mm.h:337   in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 199, name: sh   preempt_count: 1, expected: 0   3 locks held by sh/199:    #0: c00000000a0743f8 (sb_writers#3){.+.+}-{0:0}, at: vfs_write+0x324/0x438    #1: c0000000028c7058 (dtl_enable_mutex){+.+.}-{3:3}, at: vcpudispatch_stats_write+0xd4/0x5f4    #2: c0000000028c70b8 (dtl_access_lock){+.+.}-{2:2}, at: vcpudispatch_stats_write+0x220/0x5f4   CPU: 0 PID: 199 Comm: sh Not tainted 6.10.0-rc4 #152   Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1202 0xf000005 of:SLOF,HEAD hv:linux,kvm pSeries   Call Trace:     dump_stack_lvl+0x130/0x148 (unreliable)     __might_resched+0x174/0x410     kmem_cache_alloc_noprof+0x340/0x3d0     alloc_dtl_buffers+0x124/0x1ac     vcpudispatch_stats_write+0x2a8/0x5f4     proc_reg_write+0xf4/0x150     vfs_write+0xfc/0x438     ksys_write+0x88/0x148     system_call_exception+0x1c4/0x5a0     system_call_common+0xf4/0x258(CVE-2024-56701)In the Linux kernel, the following vulnerability has been resolved:  btrfs: fix use-after-free when COWing tree bock and tracing is enabled  When a COWing a tree block, at btrfs_cow_block(), and we have the tracepoint trace_btrfs_cow_block() enabled and preemption is also enabled (CONFIG_PREEMPT=y), we can trigger a use-after-free in the COWed extent buffer while inside the tracepoint code. This is because in some paths that call btrfs_cow_block(), such as btrfs_search_slot(), we are holding the last reference on the extent buffer @buf so btrfs_force_cow_block() drops the last reference on the @buf extent buffer when it calls free_extent_buffer_stale(buf), which schedules the release of the extent buffer with RCU. This means that if we are on a kernel with preemption, the current task may be preempted before calling trace_btrfs_cow_block() and the extent buffer already released by the time trace_btrfs_cow_block() is called, resulting in a use-after-free.  Fix this by moving the trace_btrfs_cow_block() from btrfs_cow_block() to btrfs_force_cow_block() before the COWed extent buffer is freed. This also has a side effect of invoking the tracepoint in the tree defrag code, at defrag.c:btrfs_realloc_node(), since btrfs_force_cow_block() is called there, but this is fine and it was actually missing there.(CVE-2024-56759)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="bpftool" release="246.0.0.145.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-246.0.0.145.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="246.0.0.145.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-246.0.0.145.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="246.0.0.145.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-246.0.0.145.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="246.0.0.145.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-246.0.0.145.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="246.0.0.145.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-246.0.0.145.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="246.0.0.145.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-246.0.0.145.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="246.0.0.145.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-246.0.0.145.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="246.0.0.145.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-246.0.0.145.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="246.0.0.145.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-246.0.0.145.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="246.0.0.145.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-246.0.0.145.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="246.0.0.145.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-246.0.0.145.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="246.0.0.145.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-246.0.0.145.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="246.0.0.145.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-246.0.0.145.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="246.0.0.145.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-246.0.0.145.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="246.0.0.145.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-246.0.0.145.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="246.0.0.145.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-246.0.0.145.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="246.0.0.145.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-246.0.0.145.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="246.0.0.145.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-246.0.0.145.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="246.0.0.145.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-246.0.0.145.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="246.0.0.145.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-246.0.0.145.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="246.0.0.145.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-246.0.0.145.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="246.0.0.145.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-246.0.0.145.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="246.0.0.145.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-246.0.0.145.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="246.0.0.145.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-246.0.0.145.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="246.0.0.145.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-246.0.0.145.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="246.0.0.145.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-246.0.0.145.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="246.0.0.145.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-246.0.0.145.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="246.0.0.145.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-246.0.0.145.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="246.0.0.145.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-246.0.0.145.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="246.0.0.145.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-246.0.0.145.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1068</id>
          <title>An update for git is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-01-24"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50349" id="CVE-2024-50349" title="CVE-2024-50349" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-52006" id="CVE-2024-52006" title="CVE-2024-52006" type="cve"></reference>
          </references>
          <description>Git is a fast, scalable, distributed revision control system with an unusually rich command set that provides both high-level operations and full access to internals. When Git asks for credentials via a terminal prompt (i.e. without using any credential helper), it prints out the host name for which the user is expected to provide a username and/or a password. At this stage, any URL-encoded parts have been decoded already, and are printed verbatim. This allows attackers to craft URLs that contain ANSI escape sequences that the terminal interpret to confuse users e.g. into providing passwords for trusted Git hosting sites when in fact they are then sent to untrusted sites that are under the attacker&#39;s control. This issue has been patch via commits `7725b81` and `c903985` which are included in release versions v2.48.1, v2.47.2, v2.46.3, v2.45.3, v2.44.3, v2.43.6, v2.42.4, v2.41.3, and v2.40.4. Users are advised to upgrade. Users unable to upgrade should avoid cloning from untrusted URLs, especially recursive clones.(CVE-2024-50349)Git is a fast, scalable, distributed revision control system with an unusually rich command set that provides both high-level operations and full access to internals. Git defines a line-based protocol that is used to exchange information between Git and Git credential helpers. Some ecosystems (most notably, .NET and node.js) interpret single Carriage Return characters as newlines, which renders the protections against CVE-2020-5260 incomplete for credential helpers that treat Carriage Returns in this way. This issue has been addressed in commit `b01b9b8` which is included in release versions v2.48.1, v2.47.2, v2.46.3, v2.45.3, v2.44.3, v2.43.6, v2.42.4, v2.41.3, and v2.40.4. Users are advised to upgrade. Users unable to upgrade should avoid cloning from untrusted URLs, especially recursive clones.(CVE-2024-52006)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="git" release="17.oe2203sp4" version="2.33.0">
                         <filename>git-2.33.0-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="git-core" release="17.oe2203sp4" version="2.33.0">
                         <filename>git-core-2.33.0-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="git-daemon" release="17.oe2203sp4" version="2.33.0">
                         <filename>git-daemon-2.33.0-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="git-debuginfo" release="17.oe2203sp4" version="2.33.0">
                         <filename>git-debuginfo-2.33.0-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="git-debugsource" release="17.oe2203sp4" version="2.33.0">
                         <filename>git-debugsource-2.33.0-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="git-email" release="17.oe2203sp4" version="2.33.0">
                         <filename>git-email-2.33.0-17.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="git-gui" release="17.oe2203sp4" version="2.33.0">
                         <filename>git-gui-2.33.0-17.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="git-help" release="17.oe2203sp4" version="2.33.0">
                         <filename>git-help-2.33.0-17.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="git-svn" release="17.oe2203sp4" version="2.33.0">
                         <filename>git-svn-2.33.0-17.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="git-web" release="17.oe2203sp4" version="2.33.0">
                         <filename>git-web-2.33.0-17.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="gitk" release="17.oe2203sp4" version="2.33.0">
                         <filename>gitk-2.33.0-17.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="perl-Git" release="17.oe2203sp4" version="2.33.0">
                         <filename>perl-Git-2.33.0-17.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="perl-Git-SVN" release="17.oe2203sp4" version="2.33.0">
                         <filename>perl-Git-SVN-2.33.0-17.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="git" release="17.oe2203sp4" version="2.33.0">
                         <filename>git-2.33.0-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="git-core" release="17.oe2203sp4" version="2.33.0">
                         <filename>git-core-2.33.0-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="git-daemon" release="17.oe2203sp4" version="2.33.0">
                         <filename>git-daemon-2.33.0-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="git-debuginfo" release="17.oe2203sp4" version="2.33.0">
                         <filename>git-debuginfo-2.33.0-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="git-debugsource" release="17.oe2203sp4" version="2.33.0">
                         <filename>git-debugsource-2.33.0-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1069</id>
          <title>An update for python-django is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-01-24"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56374" id="CVE-2024-56374" title="CVE-2024-56374" type="cve"></reference>
          </references>
          <description>An issue was discovered in Django 5.1 before 5.1.5, 5.0 before 5.0.11, and 4.2 before 4.2.18. Lack of upper-bound limit enforcement in strings passed when performing IPv6 validation could lead to a potential denial-of-service attack. The undocumented and private functions clean_ipv6_address and is_valid_ipv6_address are vulnerable, as is the django.forms.GenericIPAddressField form field. (The django.db.models.GenericIPAddressField model field is not affected.)(CVE-2024-56374)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="python-django-help" release="4.oe2203sp4" version="4.2.15">
                         <filename>python-django-help-4.2.15-4.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-Django" release="4.oe2203sp4" version="4.2.15">
                         <filename>python3-Django-4.2.15-4.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1074</id>
          <title>An update for podman is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-01-24"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-27649" id="CVE-2022-27649" title="CVE-2022-27649" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-2989" id="CVE-2022-2989" title="CVE-2022-2989" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0778" id="CVE-2023-0778" title="CVE-2023-0778" 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>A flaw was found in Podman, where containers were started incorrectly with non-empty default permissions. A vulnerability was found in Moby (Docker Engine), where containers were started incorrectly with non-empty inheritable Linux process capabilities. This flaw allows an attacker with access to programs with inheritable file capabilities to elevate those capabilities to the permitted set when execve(2) runs.(CVE-2022-27649)An incorrect handling of the supplementary groups in the Podman container engine might lead to the sensitive information disclosure or possible data modification if an attacker has direct access to the affected container where supplementary groups are used to set access permissions and is able to execute a binary code in that container.(CVE-2022-2989)A Time-of-check Time-of-use (TOCTOU) flaw was found in podman. This issue may allow a malicious user to replace a normal file in a volume with a symlink while exporting the volume, allowing for access to arbitrary files on the host file system.(CVE-2023-0778)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 epoch="1" arch="aarch64" name="podman" release="8.oe2203sp4" version="3.4.4">
                         <filename>podman-3.4.4-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="podman-debuginfo" release="8.oe2203sp4" version="3.4.4">
                         <filename>podman-debuginfo-3.4.4-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="podman-debugsource" release="8.oe2203sp4" version="3.4.4">
                         <filename>podman-debugsource-3.4.4-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="podman-gvproxy" release="8.oe2203sp4" version="3.4.4">
                         <filename>podman-gvproxy-3.4.4-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="podman-plugins" release="8.oe2203sp4" version="3.4.4">
                         <filename>podman-plugins-3.4.4-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="podman-remote" release="8.oe2203sp4" version="3.4.4">
                         <filename>podman-remote-3.4.4-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="podman-docker" release="8.oe2203sp4" version="3.4.4">
                         <filename>podman-docker-3.4.4-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="podman-help" release="8.oe2203sp4" version="3.4.4">
                         <filename>podman-help-3.4.4-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="podman" release="8.oe2203sp4" version="3.4.4">
                         <filename>podman-3.4.4-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="podman-debuginfo" release="8.oe2203sp4" version="3.4.4">
                         <filename>podman-debuginfo-3.4.4-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="podman-debugsource" release="8.oe2203sp4" version="3.4.4">
                         <filename>podman-debugsource-3.4.4-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="podman-gvproxy" release="8.oe2203sp4" version="3.4.4">
                         <filename>podman-gvproxy-3.4.4-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="podman-plugins" release="8.oe2203sp4" version="3.4.4">
                         <filename>podman-plugins-3.4.4-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="podman-remote" release="8.oe2203sp4" version="3.4.4">
                         <filename>podman-remote-3.4.4-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1081</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-01-24"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24858" id="CVE-2024-24858" title="CVE-2024-24858" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26602" id="CVE-2024-26602" title="CVE-2024-26602" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26820" id="CVE-2024-26820" title="CVE-2024-26820" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26857" id="CVE-2024-26857" title="CVE-2024-26857" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26956" id="CVE-2024-26956" title="CVE-2024-26956" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26966" id="CVE-2024-26966" title="CVE-2024-26966" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26969" id="CVE-2024-26969" title="CVE-2024-26969" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26974" id="CVE-2024-26974" title="CVE-2024-26974" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26981" id="CVE-2024-26981" title="CVE-2024-26981" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27001" id="CVE-2024-27001" title="CVE-2024-27001" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38547" id="CVE-2024-38547" title="CVE-2024-38547" 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-44969" id="CVE-2024-44969" title="CVE-2024-44969" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50279" id="CVE-2024-50279" title="CVE-2024-50279" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53050" id="CVE-2024-53050" title="CVE-2024-53050" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53226" id="CVE-2024-53226" title="CVE-2024-53226" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56549" id="CVE-2024-56549" title="CVE-2024-56549" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56626" id="CVE-2024-56626" title="CVE-2024-56626" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56648" id="CVE-2024-56648" title="CVE-2024-56648" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56690" id="CVE-2024-56690" title="CVE-2024-56690" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56728" id="CVE-2024-56728" title="CVE-2024-56728" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56758" id="CVE-2024-56758" title="CVE-2024-56758" type="cve"></reference>
          </references>
          <description>A race condition was found in the Linux kernel&#39;s net/bluetooth in {conn,adv}_{min,max}_interval_set() function. This can result in I2cap connection or broadcast abnormality issue, possibly leading to denial of service.(CVE-2024-24858)In the Linux kernel, the following vulnerability has been resolved:sched/membarrier: reduce the ability to hammer on sys_membarrierOn some systems, sys_membarrier can be very expensive, causing overallslowdowns for everything.  So put a lock on the path in order toserialize the accesses to prevent the ability for this to be called attoo high of a frequency and saturate the machine.(CVE-2024-26602)In the Linux kernel, the following vulnerability has been resolved:hv_netvsc: Register VF in netvsc_probe if NET_DEVICE_REGISTER missedIf hv_netvsc driver is unloaded and reloaded, the NET_DEVICE_REGISTERhandler cannot perform VF register successfully as the register callis received before netvsc_probe is finished. This is because weregister register_netdevice_notifier() very early( even beforevmbus_driver_register()).To fix this, we try to register each such matching VF( if it is visibleas a netdevice) at the end of netvsc_probe.(CVE-2024-26820)In the Linux kernel, the following vulnerability has been resolved:geneve: make sure to pull inner header in geneve_rx()syzbot triggered a bug in geneve_rx() [1]Issue is similar to the one I fixed in commit 8d975c15c0cd(&#34;ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()&#34;)We have to save skb-&gt;network_header in a temporary variablein order to be able to recompute the network_header pointerafter a pskb_inet_may_pull() call.pskb_inet_may_pull() makes sure the needed headers are in skb-&gt;head.[1]BUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] BUG: KMSAN: uninit-value in geneve_rx drivers/net/geneve.c:279 [inline] BUG: KMSAN: uninit-value in geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391  IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline]  geneve_rx drivers/net/geneve.c:279 [inline]  geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391  udp_queue_rcv_one_skb+0x1d39/0x1f20 net/ipv4/udp.c:2108  udp_queue_rcv_skb+0x6ae/0x6e0 net/ipv4/udp.c:2186  udp_unicast_rcv_skb+0x184/0x4b0 net/ipv4/udp.c:2346  __udp4_lib_rcv+0x1c6b/0x3010 net/ipv4/udp.c:2422  udp_rcv+0x7d/0xa0 net/ipv4/udp.c:2604  ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205  ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233  NF_HOOK include/linux/netfilter.h:314 [inline]  ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254  dst_input include/net/dst.h:461 [inline]  ip_rcv_finish net/ipv4/ip_input.c:449 [inline]  NF_HOOK include/linux/netfilter.h:314 [inline]  ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569  __netif_receive_skb_one_core net/core/dev.c:5534 [inline]  __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648  process_backlog+0x480/0x8b0 net/core/dev.c:5976  __napi_poll+0xe3/0x980 net/core/dev.c:6576  napi_poll net/core/dev.c:6645 [inline]  net_rx_action+0x8b8/0x1870 net/core/dev.c:6778  __do_softirq+0x1b7/0x7c5 kernel/softirq.c:553  do_softirq+0x9a/0xf0 kernel/softirq.c:454  __local_bh_enable_ip+0x9b/0xa0 kernel/softirq.c:381  local_bh_enable include/linux/bottom_half.h:33 [inline]  rcu_read_unlock_bh include/linux/rcupdate.h:820 [inline]  __dev_queue_xmit+0x2768/0x51c0 net/core/dev.c:4378  dev_queue_xmit include/linux/netdevice.h:3171 [inline]  packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276  packet_snd net/packet/af_packet.c:3081 [inline]  packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113  sock_sendmsg_nosec net/socket.c:730 [inline]  __sock_sendmsg net/socket.c:745 [inline]  __sys_sendto+0x735/0xa10 net/socket.c:2191  __do_sys_sendto net/socket.c:2203 [inline]  __se_sys_sendto net/socket.c:2199 [inline]  __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199  do_syscall_x64 arch/x86/entry/common.c:52 [inline]  do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6bUninit was created at:  slab_post_alloc_hook mm/slub.c:3819 [inline]  slab_alloc_node mm/slub.c:3860 [inline]  kmem_cache_alloc_node+0x5cb/0xbc0 mm/slub.c:3903  kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560  __alloc_skb+0x352/0x790 net/core/skbuff.c:651  alloc_skb include/linux/skbuff.h:1296 [inline]  alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6394  sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2783  packet_alloc_skb net/packet/af_packet.c:2930 [inline]  packet_snd net/packet/af_packet.c:3024 [inline]  packet_sendmsg+0x70c2/0x9f10 net/packet/af_packet.c:3113  sock_sendmsg_nosec net/socket.c:730 [inline]  __sock_sendmsg net/socket.c:745 [inline]  __sys_sendto+0x735/0xa10 net/socket.c:2191  __do_sys_sendto net/socket.c:2203 [inline]  __se_sys_sendto net/socket.c:2199 [inline]  __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199  do_syscall_x64 arch/x86/entry/common.c:52 [inline]  do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b(CVE-2024-26857)In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix failure to detect DAT corruption in btree and direct mappingsPatch series &#34;nilfs2: fix kernel bug at submit_bh_wbc()&#34;.This resolves a kernel BUG reported by syzbot.  Since there are twoflaws involved, I&#39;ve made each one a separate patch.The first patch alone resolves the syzbot-reported bug, but I thinkboth fixes should be sent to stable, so I&#39;ve tagged them as such.This patch (of 2):Syzbot has reported a kernel bug in submit_bh_wbc() when writing file datato a nilfs2 file system whose metadata is corrupted.There are two flaws involved in this issue.The first flaw is that when nilfs_get_block() locates a data block usingbtree or direct mapping, if the disk address translation routinenilfs_dat_translate() fails with internal code -ENOENT due to DAT metadatacorruption, it can be passed back to nilfs_get_block().  This causesnilfs_get_block() to misidentify an existing block as non-existent,causing both data block lookup and insertion to fail inconsistently.The second flaw is that nilfs_get_block() returns a successful status inthis inconsistent state.  This causes the caller __block_write_begin_int()or others to request a read even though the buffer is not mapped,resulting in a BUG_ON check for the BH_Mapped flag in submit_bh_wbc()failing.This fixes the first issue by changing the return value to code -EINVALwhen a conversion using DAT fails with code -ENOENT, avoiding theconflicting condition that leads to the kernel bug described above.  Here,code -EINVAL indicates that metadata corruption was detected during theblock lookup, which will be properly handled as a file system error andconverted to -EIO when passing through the nilfs2 bmap layer.(CVE-2024-26956)In the Linux kernel, the following vulnerability has been resolved:clk: qcom: mmcc-apq8084: 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-26966)In the Linux kernel, the following vulnerability has been resolved:clk: qcom: gcc-ipq8074: 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-26969)In the Linux kernel, the following vulnerability has been resolved:crypto: qat - resolve race condition during AER recoveryDuring the PCI AER system&#39;s error recovery process, the kernel drivermay encounter a race condition with freeing the reset_data structure&#39;smemory. If the device restart will take more than 10 seconds the functionscheduling that restart will exit due to a timeout, and the reset_datastructure will be freed. However, this data structure is used forcompletion notification after the restart is completed, which leadsto a UAF bug.This results in a KFENCE bug notice.  BUG: KFENCE: use-after-free read in adf_device_reset_worker+0x38/0xa0 [intel_qat]  Use-after-free read at 0x00000000bc56fddf (in kfence-#142):  adf_device_reset_worker+0x38/0xa0 [intel_qat]  process_one_work+0x173/0x340To resolve this race condition, the memory associated to the containerof the work_struct is freed on the worker if the timeout expired,otherwise on the function that schedules the worker.The timeout detection can be done by checking if the caller isstill waiting for completion or not by using completion_done() function.(CVE-2024-26974)In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix OOB in nilfs_set_de_typeThe size of the nilfs_type_by_mode array in the fs/nilfs2/dir.c file isdefined as &#34;S_IFMT &gt;&gt; S_SHIFT&#34;, but the nilfs_set_de_type() function,which uses this array, specifies the index to read from the array in thesame way as &#34;(mode &amp; S_IFMT) &gt;&gt; S_SHIFT&#34;.static void nilfs_set_de_type(struct nilfs_dir_entry *de, struct inode *inode){&#x9;umode_t mode = inode-&gt;i_mode;&#x9;de-&gt;file_type = nilfs_type_by_mode[(mode &amp; S_IFMT)&gt;&gt;S_SHIFT]; // oob}However, when the index is determined this way, an out-of-bounds (OOB)error occurs by referring to an index that is 1 larger than the array sizewhen the condition &#34;mode &amp; S_IFMT == S_IFMT&#34; is satisfied.  Therefore, apatch to resize the nilfs_type_by_mode array should be applied to preventOOB errors.(CVE-2024-26981)In the Linux kernel, the following vulnerability has been resolved:comedi: vmk80xx: fix incomplete endpoint checkingWhile vmk80xx does have endpoint checking implemented, some thingscan fall through the cracks. Depending on the hardware model,URBs can have either bulk or interrupt type, and current versionof vmk80xx_find_usb_endpoints() function does not take that fullyinto account. While this warning does not seem to be too harmful,at the very least it will crash systems with &#39;panic_on_warn&#39; set onthem.Fix the issue found by Syzkaller [1] by somewhat simplifying theendpoint checking process with usb_find_common_endpoints() andensuring that only expected endpoint types are present.This patch has not been tested on real hardware.[1] Syzkaller report:usb 1-1: BOGUS urb xfer, pipe 1 != type 3WARNING: CPU: 0 PID: 781 at drivers/usb/core/urb.c:504 usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503...Call Trace: &lt;TASK&gt; usb_start_wait_urb+0x113/0x520 drivers/usb/core/message.c:59 vmk80xx_reset_device drivers/comedi/drivers/vmk80xx.c:227 [inline] vmk80xx_auto_attach+0xa1c/0x1a40 drivers/comedi/drivers/vmk80xx.c:818 comedi_auto_config+0x238/0x380 drivers/comedi/drivers.c:1067 usb_probe_interface+0x5cd/0xb00 drivers/usb/core/driver.c:399...Similar issue also found by Syzkaller:(CVE-2024-27001)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: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:s390/sclp: Prevent release of buffer in I/OWhen a task waiting for completion of a Store Data operation isinterrupted, an attempt is made to halt this operation. If this attemptfails due to a hardware or firmware problem, there is a chance that theSCLP facility might store data into buffers referenced by the originaloperation at a later time.Handle this situation by not releasing the referenced data buffers ifthe halt attempt fails. For current use cases, this might result in aleak of few pages of memory in case of a rare hardware/firmwaremalfunction.(CVE-2024-44969)In the Linux kernel, the following vulnerability has been resolved:dm cache: fix out-of-bounds access to the dirty bitset when resizingdm-cache checks the dirty bits of the cache blocks to be dropped whenshrinking the fast device, but an index bug in bitset iteration causesout-of-bounds access.Reproduce steps:1. create a cache device of 1024 cache blocks (128 bytes dirty bitset)dmsetup create cmeta --table &#34;0 8192 linear /dev/sdc 0&#34;dmsetup create cdata --table &#34;0 131072 linear /dev/sdc 8192&#34;dmsetup create corig --table &#34;0 524288 linear /dev/sdc 262144&#34;dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=directdmsetup create cache --table &#34;0 524288 cache /dev/mapper/cmeta \/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0&#34;2. shrink the fast device to 512 cache blocks, triggering out-of-bounds   access to the dirty bitset (offset 0x80)dmsetup suspend cachedmsetup reload cdata --table &#34;0 65536 linear /dev/sdc 8192&#34;dmsetup resume cdatadmsetup resume cacheKASAN reports:  BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0  Read of size 8 at addr ffffc900000f3080 by task dmsetup/131  (...snip...)  The buggy address belongs to the virtual mapping at   [ffffc900000f3000, ffffc900000f5000) created by:   cache_ctr+0x176a/0x35f0  (...snip...)  Memory state around the buggy address:   ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8   ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  &gt;ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8                     ^   ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8   ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8Fix by making the index post-incremented.(CVE-2024-50279)In the Linux kernel, the following vulnerability has been resolved:drm/i915/hdcp: Add encoder check in hdcp2_get_capabilityAdd encoder check in intel_hdcp2_get_capability to avoidnull pointer error.(CVE-2024-53050)In the Linux kernel, the following vulnerability has been resolved:RDMA/hns: Fix NULL pointer derefernce in hns_roce_map_mr_sg()ib_map_mr_sg() allows ULPs to specify NULL as the sg_offset argument.The driver needs to check whether it is a NULL pointer beforedereferencing it.(CVE-2024-53226)In the Linux kernel, the following vulnerability has been resolved:cachefiles: Fix NULL pointer dereference in object-&gt;fileAt present, the object-&gt;file has the NULL pointer dereference problem inondemand-mode. The root cause is that the allocated fd and object-&gt;filelifetime are inconsistent, and the user-space invocation to anon_fd usesobject-&gt;file. Following is the process that triggers the issue:&#x9;  [write fd]&#x9;&#x9;&#x9;&#x9;[umount]cachefiles_ondemand_fd_write_iter&#x9;&#x9;&#x9;&#x9;       fscache_cookie_state_machine&#x9;&#x9;&#x9;&#x9;&#x9; cachefiles_withdraw_cookie  if (!file) return -ENOBUFS&#x9;&#x9;&#x9;&#x9;&#x9;   cachefiles_clean_up_object&#x9;&#x9;&#x9;&#x9;&#x9;     cachefiles_unmark_inode_in_use&#x9;&#x9;&#x9;&#x9;&#x9;     fput(object-&gt;file)&#x9;&#x9;&#x9;&#x9;&#x9;     object-&gt;file = NULL  // file NULL pointer dereference!  __cachefiles_write(..., file, ...)Fix this issue by add an additional reference count to the object-&gt;filebefore write/llseek, and decrement after it finished.(CVE-2024-56549)In the Linux kernel, the following vulnerability has been resolved:ksmbd: fix Out-of-Bounds Write in ksmbd_vfs_stream_writeAn offset from client could be a negative value, It could allowsto write data outside the bounds of the allocated buffer.Note that this issue is coming when setting&#39;vfs objects = streams_xattr parameter&#39; in ksmbd.conf..(CVE-2024-56626)In the Linux kernel, the following vulnerability has been resolved:net: hsr: avoid potential out-of-bound access in fill_frame_info()syzbot is able to feed a packet with 14 bytes, pretendingit is a vlan one.Since fill_frame_info() is relying on skb-&gt;mac_len already,extend the check to cover this case.BUG: KMSAN: uninit-value in fill_frame_info net/hsr/hsr_forward.c:709 [inline] BUG: KMSAN: uninit-value in hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724  fill_frame_info net/hsr/hsr_forward.c:709 [inline]  hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724  hsr_dev_xmit+0x2f0/0x350 net/hsr/hsr_device.c:235  __netdev_start_xmit include/linux/netdevice.h:5002 [inline]  netdev_start_xmit include/linux/netdevice.h:5011 [inline]  xmit_one net/core/dev.c:3590 [inline]  dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3606  __dev_queue_xmit+0x366a/0x57d0 net/core/dev.c:4434  dev_queue_xmit include/linux/netdevice.h:3168 [inline]  packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276  packet_snd net/packet/af_packet.c:3146 [inline]  packet_sendmsg+0x91ae/0xa6f0 net/packet/af_packet.c:3178  sock_sendmsg_nosec net/socket.c:711 [inline]  __sock_sendmsg+0x30f/0x380 net/socket.c:726  __sys_sendto+0x594/0x750 net/socket.c:2197  __do_sys_sendto net/socket.c:2204 [inline]  __se_sys_sendto net/socket.c:2200 [inline]  __x64_sys_sendto+0x125/0x1d0 net/socket.c:2200  x64_sys_call+0x346a/0x3c30 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:4091 [inline]  slab_alloc_node mm/slub.c:4134 [inline]  kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186  kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587  __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678  alloc_skb include/linux/skbuff.h:1323 [inline]  alloc_skb_with_frags+0xc8/0xd00 net/core/skbuff.c:6612  sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2881  packet_alloc_skb net/packet/af_packet.c:2995 [inline]  packet_snd net/packet/af_packet.c:3089 [inline]  packet_sendmsg+0x74c6/0xa6f0 net/packet/af_packet.c:3178  sock_sendmsg_nosec net/socket.c:711 [inline]  __sock_sendmsg+0x30f/0x380 net/socket.c:726  __sys_sendto+0x594/0x750 net/socket.c:2197  __do_sys_sendto net/socket.c:2204 [inline]  __se_sys_sendto net/socket.c:2200 [inline]  __x64_sys_sendto+0x125/0x1d0 net/socket.c:2200  x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45  do_syscall_x64 arch/x86/entry/common.c:52 [inline]  do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-56648)In the Linux kernel, the following vulnerability has been resolved:crypto: pcrypt - Call crypto layer directly when padata_do_parallel() return -EBUSYSince commit 8f4f68e788c3 (&#34;crypto: pcrypt - Fix hungtask forPADATA_RESET&#34;), the pcrypt encryption and decryption operations return-EAGAIN when the CPU goes online or offline. In alg_test(), a WARN isgenerated when pcrypt_aead_decrypt() or pcrypt_aead_encrypt() returns-EAGAIN, the unnecessary panic will occur when panic_on_warn set 1.Fix this issue by calling crypto layer directly without parallelizationin that case.(CVE-2024-56690)In the Linux kernel, the following vulnerability has been resolved:octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_ethtool.cAdd error pointer check after calling otx2_mbox_get_rsp().(CVE-2024-56728)In the Linux kernel, the following vulnerability has been resolved:btrfs: check folio mapping after unlock in relocate_one_folio()When we call btrfs_read_folio() to bring a folio uptodate, we unlock thefolio. The result of that is that a different thread can modify themapping (like remove it with invalidate) before we call folio_lock().This results in an invalid page and we need to try again.In particular, if we are relocating concurrently with aborting atransaction, this can result in a crash like the following:  BUG: kernel NULL pointer dereference, address: 0000000000000000  PGD 0 P4D 0  Oops: 0000 [#1] SMP  CPU: 76 PID: 1411631 Comm: kworker/u322:5  Workqueue: events_unbound btrfs_reclaim_bgs_work  RIP: 0010:set_page_extent_mapped+0x20/0xb0  RSP: 0018:ffffc900516a7be8 EFLAGS: 00010246  RAX: ffffea009e851d08 RBX: ffffea009e0b1880 RCX: 0000000000000000  RDX: 0000000000000000 RSI: ffffc900516a7b90 RDI: ffffea009e0b1880  RBP: 0000000003573000 R08: 0000000000000001 R09: ffff88c07fd2f3f0  R10: 0000000000000000 R11: 0000194754b575be R12: 0000000003572000  R13: 0000000003572fff R14: 0000000000100cca R15: 0000000005582fff  FS:  0000000000000000(0000) GS:ffff88c07fd00000(0000) knlGS:0000000000000000  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  CR2: 0000000000000000 CR3: 000000407d00f002 CR4: 00000000007706f0  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400  PKRU: 55555554  Call Trace:  &lt;TASK&gt;  ? __die+0x78/0xc0  ? page_fault_oops+0x2a8/0x3a0  ? __switch_to+0x133/0x530  ? wq_worker_running+0xa/0x40  ? exc_page_fault+0x63/0x130  ? asm_exc_page_fault+0x22/0x30  ? set_page_extent_mapped+0x20/0xb0  relocate_file_extent_cluster+0x1a7/0x940  relocate_data_extent+0xaf/0x120  relocate_block_group+0x20f/0x480  btrfs_relocate_block_group+0x152/0x320  btrfs_relocate_chunk+0x3d/0x120  btrfs_reclaim_bgs_work+0x2ae/0x4e0  process_scheduled_works+0x184/0x370  worker_thread+0xc6/0x3e0  ? blk_add_timer+0xb0/0xb0  kthread+0xae/0xe0  ? flush_tlb_kernel_range+0x90/0x90  ret_from_fork+0x2f/0x40  ? flush_tlb_kernel_range+0x90/0x90  ret_from_fork_asm+0x11/0x20  &lt;/TASK&gt;This occurs because cleanup_one_transaction() callsdestroy_delalloc_inodes() which calls invalidate_inode_pages2() whichtakes the folio_lock before setting mapping to NULL. We fail to checkthis, and subsequently call set_extent_mapping(), which assumes thatmapping != NULL (in fact it asserts that in debug mode)Note that the &#34;fixes&#34; patch here is not the one that introduced therace (the very first iteration of this code from 2009) but a more recentchange that made this particular crash happen in practice.(CVE-2024-56758)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="bpftool" release="247.0.0.146.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="247.0.0.146.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="247.0.0.146.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="247.0.0.146.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="247.0.0.146.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="247.0.0.146.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="247.0.0.146.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="247.0.0.146.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="247.0.0.146.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="247.0.0.146.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="247.0.0.146.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="247.0.0.146.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="247.0.0.146.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="247.0.0.146.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="247.0.0.146.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-247.0.0.146.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="247.0.0.146.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="247.0.0.146.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="247.0.0.146.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="247.0.0.146.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="247.0.0.146.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="247.0.0.146.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="247.0.0.146.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="247.0.0.146.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="247.0.0.146.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="247.0.0.146.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="247.0.0.146.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="247.0.0.146.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="247.0.0.146.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="247.0.0.146.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="247.0.0.146.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-247.0.0.146.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1082</id>
          <title>An update for logback is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-01-24"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-12798" id="CVE-2024-12798" title="CVE-2024-12798" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-12801" id="CVE-2024-12801" title="CVE-2024-12801" type="cve"></reference>
          </references>
          <description>ACE vulnerability in JaninoEventEvaluator  by QOS.CH logback-core      upto including version 0.1 to 1.3.14 and 1.4.0 to 1.5.12 in Java applications allows      attacker to execute arbitrary code by compromising an existing      logback configuration file or by injecting an environment variable      before program execution.Malicious logback configuration files can allow the attacker to execute arbitrary code using the JaninoEventEvaluator extension.A successful attack requires the user to have write access to a configuration file. Alternatively, the attacker could inject a malicious environment variable pointing to a malicious configuration file. In both cases, the attack requires existing privilege.(CVE-2024-12798)Server-Side Request Forgery (SSRF) in SaxEventRecorder by QOS.CH logback version 0.1 to 1.3.14 and 1.4.0 to 1.5.12  on the Java platform, allows an attacker to forge requests by compromising logback configuration files in XML.The attacks involves the modification of DOCTYPE declaration in  XML configuration files.(CVE-2024-12801)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="logback" release="4.oe2203sp4" version="1.2.8">
                         <filename>logback-1.2.8-4.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="logback-access" release="4.oe2203sp4" version="1.2.8">
                         <filename>logback-access-1.2.8-4.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="logback-examples" release="4.oe2203sp4" version="1.2.8">
                         <filename>logback-examples-1.2.8-4.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="logback-help" release="4.oe2203sp4" version="1.2.8">
                         <filename>logback-help-1.2.8-4.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1087</id>
          <title>An update for qt5-qtconnectivity is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2025-02-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-23050" id="CVE-2025-23050" title="CVE-2025-23050" type="cve"></reference>
          </references>
          <description>(CVE-2025-23050)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="qt5-qtconnectivity" release="2.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtconnectivity-5.15.2-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtconnectivity-debuginfo" release="2.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtconnectivity-debuginfo-5.15.2-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtconnectivity-debugsource" release="2.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtconnectivity-debugsource-5.15.2-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtconnectivity-devel" release="2.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtconnectivity-devel-5.15.2-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtconnectivity-help" release="2.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtconnectivity-help-5.15.2-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtconnectivity" release="2.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtconnectivity-5.15.2-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtconnectivity-debuginfo" release="2.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtconnectivity-debuginfo-5.15.2-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtconnectivity-debugsource" release="2.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtconnectivity-debugsource-5.15.2-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtconnectivity-devel" release="2.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtconnectivity-devel-5.15.2-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtconnectivity-help" release="2.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtconnectivity-help-5.15.2-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1096</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-02-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52434" id="CVE-2023-52434" title="CVE-2023-52434" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52480" id="CVE-2023-52480" title="CVE-2023-52480" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52614" id="CVE-2023-52614" title="CVE-2023-52614" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52627" id="CVE-2023-52627" title="CVE-2023-52627" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52913" id="CVE-2023-52913" title="CVE-2023-52913" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24857" id="CVE-2024-24857" title="CVE-2024-24857" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24859" id="CVE-2024-24859" title="CVE-2024-24859" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26659" id="CVE-2024-26659" title="CVE-2024-26659" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26664" id="CVE-2024-26664" title="CVE-2024-26664" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26673" id="CVE-2024-26673" title="CVE-2024-26673" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26747" id="CVE-2024-26747" title="CVE-2024-26747" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26748" id="CVE-2024-26748" title="CVE-2024-26748" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26749" id="CVE-2024-26749" title="CVE-2024-26749" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26753" id="CVE-2024-26753" title="CVE-2024-26753" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26781" id="CVE-2024-26781" title="CVE-2024-26781" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26790" id="CVE-2024-26790" title="CVE-2024-26790" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26793" id="CVE-2024-26793" title="CVE-2024-26793" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26952" id="CVE-2024-26952" title="CVE-2024-26952" 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-27004" id="CVE-2024-27004" title="CVE-2024-27004" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36479" id="CVE-2024-36479" title="CVE-2024-36479" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-37021" id="CVE-2024-37021" title="CVE-2024-37021" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40965" id="CVE-2024-40965" title="CVE-2024-40965" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50194" id="CVE-2024-50194" title="CVE-2024-50194" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50280" id="CVE-2024-50280" title="CVE-2024-50280" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53131" id="CVE-2024-53131" title="CVE-2024-53131" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53183" id="CVE-2024-53183" title="CVE-2024-53183" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53198" id="CVE-2024-53198" title="CVE-2024-53198" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53201" id="CVE-2024-53201" title="CVE-2024-53201" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56539" id="CVE-2024-56539" title="CVE-2024-56539" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56571" id="CVE-2024-56571" title="CVE-2024-56571" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56588" id="CVE-2024-56588" title="CVE-2024-56588" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56610" id="CVE-2024-56610" title="CVE-2024-56610" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56611" id="CVE-2024-56611" title="CVE-2024-56611" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56623" id="CVE-2024-56623" title="CVE-2024-56623" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56688" id="CVE-2024-56688" title="CVE-2024-56688" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56704" id="CVE-2024-56704" title="CVE-2024-56704" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56715" id="CVE-2024-56715" title="CVE-2024-56715" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56746" id="CVE-2024-56746" title="CVE-2024-56746" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57892" id="CVE-2024-57892" title="CVE-2024-57892" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:smb: client: fix potential OOBs in smb2_parse_contexts()Validate offsets and lengths before dereferencing create contexts insmb2_parse_contexts().This fixes following oops when accessing invalid create contexts fromserver:  BUG: unable to handle page fault for address: ffff8881178d8cc3  #PF: supervisor read access in kernel mode  #PF: error_code(0x0000) - not-present page  PGD 4a01067 P4D 4a01067 PUD 0  Oops: 0000 [#1] PREEMPT SMP NOPTI  CPU: 3 PID: 1736 Comm: mount.cifs Not tainted 6.7.0-rc4 #1  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS  rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014  RIP: 0010:smb2_parse_contexts+0xa0/0x3a0 [cifs]  Code: f8 10 75 13 48 b8 93 ad 25 50 9c b4 11 e7 49 39 06 0f 84 d2 00  00 00 8b 45 00 85 c0 74 61 41 29 c5 48 01 c5 41 83 fd 0f 76 55 &lt;0f&gt; b7  7d 04 0f b7 45 06 4c 8d 74 3d 00 66 83 f8 04 75 bc ba 04 00  RSP: 0018:ffffc900007939e0 EFLAGS: 00010216  RAX: ffffc90000793c78 RBX: ffff8880180cc000 RCX: ffffc90000793c90  RDX: ffffc90000793cc0 RSI: ffff8880178d8cc0 RDI: ffff8880180cc000  RBP: ffff8881178d8cbf R08: ffffc90000793c22 R09: 0000000000000000  R10: ffff8880180cc000 R11: 0000000000000024 R12: 0000000000000000  R13: 0000000000000020 R14: 0000000000000000 R15: ffffc90000793c22  FS: 00007f873753cbc0(0000) GS:ffff88806bc00000(0000)  knlGS:0000000000000000  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  CR2: ffff8881178d8cc3 CR3: 00000000181ca000 CR4: 0000000000750ef0  PKRU: 55555554  Call Trace:   &lt;TASK&gt;   ? __die+0x23/0x70   ? page_fault_oops+0x181/0x480   ? search_module_extables+0x19/0x60   ? srso_alias_return_thunk+0x5/0xfbef5   ? exc_page_fault+0x1b6/0x1c0   ? asm_exc_page_fault+0x26/0x30   ? smb2_parse_contexts+0xa0/0x3a0 [cifs]   SMB2_open+0x38d/0x5f0 [cifs]   ? smb2_is_path_accessible+0x138/0x260 [cifs]   smb2_is_path_accessible+0x138/0x260 [cifs]   cifs_is_path_remote+0x8d/0x230 [cifs]   cifs_mount+0x7e/0x350 [cifs]   cifs_smb3_do_mount+0x128/0x780 [cifs]   smb3_get_tree+0xd9/0x290 [cifs]   vfs_get_tree+0x2c/0x100   ? capable+0x37/0x70   path_mount+0x2d7/0xb80   ? srso_alias_return_thunk+0x5/0xfbef5   ? _raw_spin_unlock_irqrestore+0x44/0x60   __x64_sys_mount+0x11a/0x150   do_syscall_64+0x47/0xf0   entry_SYSCALL_64_after_hwframe+0x6f/0x77  RIP: 0033:0x7f8737657b1e(CVE-2023-52434)In the Linux kernel, the following vulnerability has been resolved:ksmbd: fix race condition between session lookup and expire Thread A                        +  Thread B ksmbd_session_lookup            |  smb2_sess_setup   sess = xa_load                |                                 |                                 |    xa_erase(&amp;conn-&gt;sessions, sess-&gt;id);                                 |                                 |    ksmbd_session_destroy(sess) --&gt; kfree(sess)                                 |   // UAF!                       |   sess-&gt;last_active = jiffies   |                                 +This patch add rwsem to fix race condition between ksmbd_session_lookupand ksmbd_expire_session.(CVE-2023-52480)In the Linux kernel, the following vulnerability has been resolved:PM / devfreq: Fix buffer overflow in trans_stat_showFix buffer overflow in trans_stat_show().Convert simple snprintf to the more secure scnprintf with size ofPAGE_SIZE.Add condition checking if we are exceeding PAGE_SIZE and exit early fromloop. Also add at the end a warning that we exceeded PAGE_SIZE and thatstats is disabled.Return -EFBIG in the case where we don&#39;t have enough space to write thefull transition table.Also document in the ABI that this function can return -EFBIG error.(CVE-2023-52614)In the Linux kernel, the following vulnerability has been resolved:iio: adc: ad7091r: Allow users to configure device eventsAD7091R-5 devices are supported by the ad7091r-5 driver together withthe ad7091r-base driver. Those drivers declared iio events for notifyinguser space when ADC readings fall bellow the thresholds of low limitregisters or above the values set in high limit registers.However, to configure iio events and their thresholds, a set of callbackfunctions must be implemented and those were not present until now.The consequence of trying to configure ad7091r-5 events without theproper callback functions was a null pointer dereference in the kernelbecause the pointers to the callback functions were not set.Implement event configuration callbacks allowing users to read/writeevent thresholds and enable/disable event generation.Since the event spec structs are generic to AD7091R devices, also movethose from the ad7091r-5 driver the base driver so they can be reusedwhen support for ad7091r-2/-4/-8 be added.(CVE-2023-52627)In the Linux kernel, the following vulnerability has been resolved:drm/i915: Fix potential context UAFsgem_context_register() makes the context visible to userspace, and whichpoint a separate thread can trigger the I915_GEM_CONTEXT_DESTROY ioctl.So we need to ensure that nothing uses the ctx ptr after this.  And weneed to ensure that adding the ctx to the xarray is the *last* thingthat gem_context_register() does with the ctx pointer.[tursulin: Stable and fixes tags add/tidy.](cherry picked from commit bed4b455cf5374e68879be56971c1da563bcd90c)(CVE-2023-52913)A race condition was found in the Linux kernel&#39;s net/bluetooth device driver in conn_info_{min,max}_age_set() function. This can result in integrity overflow issue, possibly leading to bluetooth connection abnormality or denial of service.(CVE-2024-24857)A race condition was found in the Linux kernel&#39;s net/bluetooth in sniff_{min,max}_interval_set() function. This can result in a bluetooth sniffing exception issue, possibly leading denial of service.(CVE-2024-24859)In the Linux kernel, the following vulnerability has been resolved:xhci: handle isoc Babble and Buffer Overrun events properlyxHCI 4.9 explicitly forbids assuming that the xHC has released itsownership of a multi-TRB TD when it reports an error on one of theearly TRBs. Yet the driver makes such assumption and releases the TD,allowing the remaining TRBs to be freed or overwritten by new TDs.The xHC should also report completion of the final TRB due to its IOCflag being set by us, regardless of prior errors. This event cannotbe recognized if the TD has already been freed earlier, resulting in&#34;Transfer event TRB DMA ptr not part of current TD&#34; error message.Fix this by reusing the logic for processing isoc Transaction Errors.This also handles hosts which fail to report the final completion.Fix transfer length reporting on Babble errors. They may be caused bydevice malfunction, no guarantee that the buffer has been filled.(CVE-2024-26659)In the Linux kernel, the following vulnerability has been resolved:hwmon: (coretemp) Fix out-of-bounds memory accessFix a bug that pdata-&gt;cpu_map[] is set before out-of-bounds check.The problem might be triggered on systems with more than 128 cores perpackage.(CVE-2024-26664)In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_ct: sanitize layer 3 and 4 protocol number in custom expectations- Disallow families other than NFPROTO_{IPV4,IPV6,INET}.- Disallow layer 4 protocol with no ports, since destination port is a  mandatory attribute for this object.(CVE-2024-26673)In the Linux kernel, the following vulnerability has been resolved:usb: roles: fix NULL pointer issue when put module&#39;s referenceIn current design, usb role class driver will get usb_role_switch parent&#39;smodule reference after the user get usb_role_switch device and put thereference after the user put the usb_role_switch device. However, theparent device of usb_role_switch may be removed before the user put theusb_role_switch. If so, then, NULL pointer issue will be met when the userput the parent module&#39;s reference.This will save the module pointer in structure of usb_role_switch. Then,we don&#39;t need to find module by iterating long relations.(CVE-2024-26747)In the Linux kernel, the following vulnerability has been resolved:usb: cdns3: fix memory double free when handle zero packet829  if (request-&gt;complete) {830          spin_unlock(&amp;priv_dev-&gt;lock);831          usb_gadget_giveback_request(&amp;priv_ep-&gt;endpoint,832                                    request);833          spin_lock(&amp;priv_dev-&gt;lock);834  }835836  if (request-&gt;buf == priv_dev-&gt;zlp_buf)837      cdns3_gadget_ep_free_request(&amp;priv_ep-&gt;endpoint, request);Driver append an additional zero packet request when queue a packet, whichlength mod max packet size is 0. When transfer complete, run to line 831,usb_gadget_giveback_request() will free this requestion. 836 condition istrue, so cdns3_gadget_ep_free_request() free this request again.Log:[ 1920.140696][  T150] BUG: KFENCE: use-after-free read in cdns3_gadget_giveback+0x134/0x2c0 [cdns3][ 1920.140696][  T150][ 1920.151837][  T150] Use-after-free read at 0x000000003d1cd10b (in kfence-#36):[ 1920.159082][  T150]  cdns3_gadget_giveback+0x134/0x2c0 [cdns3][ 1920.164988][  T150]  cdns3_transfer_completed+0x438/0x5f8 [cdns3]Add check at line 829, skip call usb_gadget_giveback_request() if it isadditional zero length packet request. Needn&#39;t callusb_gadget_giveback_request() because it is allocated in this driver.(CVE-2024-26748)In the Linux kernel, the following vulnerability has been resolved:usb: cdns3: fixed memory use after free at cdns3_gadget_ep_disable()  ...  cdns3_gadget_ep_free_request(&amp;priv_ep-&gt;endpoint, &amp;priv_req-&gt;request);  list_del_init(&amp;priv_req-&gt;list);  ...&#39;priv_req&#39; actually free at cdns3_gadget_ep_free_request(). Butlist_del_init() use priv_req-&gt;list after it.[ 1542.642868][  T534] BUG: KFENCE: use-after-free read in __list_del_entry_valid+0x10/0xd4[ 1542.642868][  T534][ 1542.653162][  T534] Use-after-free read at 0x000000009ed0ba99 (in kfence-#3):[ 1542.660311][  T534]  __list_del_entry_valid+0x10/0xd4[ 1542.665375][  T534]  cdns3_gadget_ep_disable+0x1f8/0x388 [cdns3][ 1542.671571][  T534]  usb_ep_disable+0x44/0xe4[ 1542.675948][  T534]  ffs_func_eps_disable+0x64/0xc8[ 1542.680839][  T534]  ffs_func_set_alt+0x74/0x368[ 1542.685478][  T534]  ffs_func_disable+0x18/0x28Move list_del_init() before cdns3_gadget_ep_free_request() to resolve thisproblem.(CVE-2024-26749)In the Linux kernel, the following vulnerability has been resolved:crypto: virtio/akcipher - Fix stack overflow on memcpysizeof(struct virtio_crypto_akcipher_session_para) is less thansizeof(struct virtio_crypto_op_ctrl_req::u), copying more bytes fromstack variable leads stack overflow. Clang reports this issue bycommands:make -j CC=clang-14 mrproper &gt;/dev/null 2&gt;&amp;1make -j O=/tmp/crypto-build CC=clang-14 allmodconfig &gt;/dev/null 2&gt;&amp;1make -j O=/tmp/crypto-build W=1 CC=clang-14 drivers/crypto/virtio/  virtio_crypto_akcipher_algs.o(CVE-2024-26753)In the Linux kernel, the following vulnerability has been resolved:mptcp: fix possible deadlock in subflow diagSyzbot and Eric reported a lockdep splat in the subflow diag:   WARNING: possible circular locking dependency detected   6.8.0-rc4-syzkaller-00212-g40b9385dd8e6 #0 Not tainted   syz-executor.2/24141 is trying to acquire lock:   ffff888045870130 (k-sk_lock-AF_INET6){+.+.}-{0:0}, at:   tcp_diag_put_ulp net/ipv4/tcp_diag.c:100 [inline]   ffff888045870130 (k-sk_lock-AF_INET6){+.+.}-{0:0}, at:   tcp_diag_get_aux+0x738/0x830 net/ipv4/tcp_diag.c:137   but task is already holding lock:   ffffc9000135e488 (&amp;h-&gt;lhash2[i].lock){+.+.}-{2:2}, at: spin_lock   include/linux/spinlock.h:351 [inline]   ffffc9000135e488 (&amp;h-&gt;lhash2[i].lock){+.+.}-{2:2}, at:   inet_diag_dump_icsk+0x39f/0x1f80 net/ipv4/inet_diag.c:1038   which lock already depends on the new lock.   the existing dependency chain (in reverse order) is:   -&gt; #1 (&amp;h-&gt;lhash2[i].lock){+.+.}-{2:2}:   lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754   __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline]   _raw_spin_lock+0x2e/0x40 kernel/locking/spinlock.c:154   spin_lock include/linux/spinlock.h:351 [inline]   __inet_hash+0x335/0xbe0 net/ipv4/inet_hashtables.c:743   inet_csk_listen_start+0x23a/0x320 net/ipv4/inet_connection_sock.c:1261   __inet_listen_sk+0x2a2/0x770 net/ipv4/af_inet.c:217   inet_listen+0xa3/0x110 net/ipv4/af_inet.c:239   rds_tcp_listen_init+0x3fd/0x5a0 net/rds/tcp_listen.c:316   rds_tcp_init_net+0x141/0x320 net/rds/tcp.c:577   ops_init+0x352/0x610 net/core/net_namespace.c:136   __register_pernet_operations net/core/net_namespace.c:1214 [inline]   register_pernet_operations+0x2cb/0x660 net/core/net_namespace.c:1283   register_pernet_device+0x33/0x80 net/core/net_namespace.c:1370   rds_tcp_init+0x62/0xd0 net/rds/tcp.c:735   do_one_initcall+0x238/0x830 init/main.c:1236   do_initcall_level+0x157/0x210 init/main.c:1298   do_initcalls+0x3f/0x80 init/main.c:1314   kernel_init_freeable+0x42f/0x5d0 init/main.c:1551   kernel_init+0x1d/0x2a0 init/main.c:1441   ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147   ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:242   -&gt; #0 (k-sk_lock-AF_INET6){+.+.}-{0:0}:   check_prev_add kernel/locking/lockdep.c:3134 [inline]   check_prevs_add kernel/locking/lockdep.c:3253 [inline]   validate_chain+0x18ca/0x58e0 kernel/locking/lockdep.c:3869   __lock_acquire+0x1345/0x1fd0 kernel/locking/lockdep.c:5137   lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754   lock_sock_fast include/net/sock.h:1723 [inline]   subflow_get_info+0x166/0xd20 net/mptcp/diag.c:28   tcp_diag_put_ulp net/ipv4/tcp_diag.c:100 [inline]   tcp_diag_get_aux+0x738/0x830 net/ipv4/tcp_diag.c:137   inet_sk_diag_fill+0x10ed/0x1e00 net/ipv4/inet_diag.c:345   inet_diag_dump_icsk+0x55b/0x1f80 net/ipv4/inet_diag.c:1061   __inet_diag_dump+0x211/0x3a0 net/ipv4/inet_diag.c:1263   inet_diag_dump_compat+0x1c1/0x2d0 net/ipv4/inet_diag.c:1371   netlink_dump+0x59b/0xc80 net/netlink/af_netlink.c:2264   __netlink_dump_start+0x5df/0x790 net/netlink/af_netlink.c:2370   netlink_dump_start include/linux/netlink.h:338 [inline]   inet_diag_rcv_msg_compat+0x209/0x4c0 net/ipv4/inet_diag.c:1405   sock_diag_rcv_msg+0xe7/0x410   netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543   sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:280   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/0x77As noted by Eric we can break the lock dependency chain avoiddumping ---truncated---(CVE-2024-26781)In the Linux kernel, the following vulnerability has been resolved:dmaengine: fsl-qdma: fix SoC may hang on 16 byte unaligned readThere is chip (ls1028a) errata:The SoC may hang on 16 byte unaligned read transactions by QDMA.Unaligned read transactions initiated by QDMA may stall in the NOC(Network On-Chip), causing a deadlock condition. Stalled transactions willtrigger completion timeouts in PCIe controller.Workaround:Enable prefetch by setting the source descriptor prefetchable bit( SD[PF] = 1 ).Implement this workaround.(CVE-2024-26790)In the Linux kernel, the following vulnerability has been resolved:gtp: fix use-after-free and null-ptr-deref in gtp_newlink()The gtp_link_ops operations structure for the subsystem must beregistered after registering the gtp_net_ops pernet operations structure.Syzkaller hit &#39;general protection fault in gtp_genl_dump_pdp&#39; bug:[ 1010.702740] gtp: GTP module unloaded[ 1010.715877] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI[ 1010.715888] KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f][ 1010.715895] CPU: 1 PID: 128616 Comm: a.out Not tainted 6.8.0-rc6-std-def-alt1 #1[ 1010.715899] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014[ 1010.715908] RIP: 0010:gtp_newlink+0x4d7/0x9c0 [gtp][ 1010.715915] Code: 80 3c 02 00 0f 85 41 04 00 00 48 8b bb d8 05 00 00 e8 ed f6 ff ff 48 89 c2 48 89 c5 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 &lt;80&gt; 3c 02 00 0f 85 4f 04 00 00 4c 89 e2 4c 8b 6d 00 48 b8 00 00 00[ 1010.715920] RSP: 0018:ffff888020fbf180 EFLAGS: 00010203[ 1010.715929] RAX: dffffc0000000000 RBX: ffff88800399c000 RCX: 0000000000000000[ 1010.715933] RDX: 0000000000000001 RSI: ffffffff84805280 RDI: 0000000000000282[ 1010.715938] RBP: 000000000000000d R08: 0000000000000001 R09: 0000000000000000[ 1010.715942] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88800399cc80[ 1010.715947] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000400[ 1010.715953] FS:  00007fd1509ab5c0(0000) GS:ffff88805b300000(0000) knlGS:0000000000000000[ 1010.715958] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 1010.715962] CR2: 0000000000000000 CR3: 000000001c07a000 CR4: 0000000000750ee0[ 1010.715968] PKRU: 55555554[ 1010.715972] Call Trace:[ 1010.715985]  ? __die_body.cold+0x1a/0x1f[ 1010.715995]  ? die_addr+0x43/0x70[ 1010.716002]  ? exc_general_protection+0x199/0x2f0[ 1010.716016]  ? asm_exc_general_protection+0x1e/0x30[ 1010.716026]  ? gtp_newlink+0x4d7/0x9c0 [gtp][ 1010.716034]  ? gtp_net_exit+0x150/0x150 [gtp][ 1010.716042]  __rtnl_newlink+0x1063/0x1700[ 1010.716051]  ? rtnl_setlink+0x3c0/0x3c0[ 1010.716063]  ? is_bpf_text_address+0xc0/0x1f0[ 1010.716070]  ? kernel_text_address.part.0+0xbb/0xd0[ 1010.716076]  ? __kernel_text_address+0x56/0xa0[ 1010.716084]  ? unwind_get_return_address+0x5a/0xa0[ 1010.716091]  ? create_prof_cpu_mask+0x30/0x30[ 1010.716098]  ? arch_stack_walk+0x9e/0xf0[ 1010.716106]  ? stack_trace_save+0x91/0xd0[ 1010.716113]  ? stack_trace_consume_entry+0x170/0x170[ 1010.716121]  ? __lock_acquire+0x15c5/0x5380[ 1010.716139]  ? mark_held_locks+0x9e/0xe0[ 1010.716148]  ? kmem_cache_alloc_trace+0x35f/0x3c0[ 1010.716155]  ? __rtnl_newlink+0x1700/0x1700[ 1010.716160]  rtnl_newlink+0x69/0xa0[ 1010.716166]  rtnetlink_rcv_msg+0x43b/0xc50[ 1010.716172]  ? rtnl_fdb_dump+0x9f0/0x9f0[ 1010.716179]  ? lock_acquire+0x1fe/0x560[ 1010.716188]  ? netlink_deliver_tap+0x12f/0xd50[ 1010.716196]  netlink_rcv_skb+0x14d/0x440[ 1010.716202]  ? rtnl_fdb_dump+0x9f0/0x9f0[ 1010.716208]  ? netlink_ack+0xab0/0xab0[ 1010.716213]  ? netlink_deliver_tap+0x202/0xd50[ 1010.716220]  ? netlink_deliver_tap+0x218/0xd50[ 1010.716226]  ? __virt_addr_valid+0x30b/0x590[ 1010.716233]  netlink_unicast+0x54b/0x800[ 1010.716240]  ? netlink_attachskb+0x870/0x870[ 1010.716248]  ? __check_object_size+0x2de/0x3b0[ 1010.716254]  netlink_sendmsg+0x938/0xe40[ 1010.716261]  ? netlink_unicast+0x800/0x800[ 1010.716269]  ? __import_iovec+0x292/0x510[ 1010.716276]  ? netlink_unicast+0x800/0x800[ 1010.716284]  __sock_sendmsg+0x159/0x190[ 1010.716290]  ____sys_sendmsg+0x712/0x880[ 1010.716297]  ? sock_write_iter+0x3d0/0x3d0[ 1010.716304]  ? __ia32_sys_recvmmsg+0x270/0x270[ 1010.716309]  ? lock_acquire+0x1fe/0x560[ 1010.716315]  ? drain_array_locked+0x90/0x90[ 1010.716324]  ___sys_sendmsg+0xf8/0x170[ 1010.716331]  ? sendmsg_copy_msghdr+0x170/0x170[ 1010.716337]  ? lockdep_init_map---truncated---(CVE-2024-26793)In the Linux kernel, the following vulnerability has been resolved:ksmbd: fix potencial out-of-bounds when buffer offset is invalidI found potencial out-of-bounds when buffer offset fields of a few requestsis invalid. This patch set the minimum value of buffer offset field to-&gt;Buffer offset to validate buffer length.(CVE-2024-26952)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:clk: Get runtime PM before walking tree during disable_unusedDoug reported [1] the following hung task: INFO: task swapper/0:1 blocked for more than 122 seconds.       Not tainted 5.15.149-21875-gf795ebc40eb8 #1 &#34;echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs&#34; disables this message. task:swapper/0       state:D stack:    0 pid:    1 ppid:     0 flags:0x00000008 Call trace:  __switch_to+0xf4/0x1f4  __schedule+0x418/0xb80  schedule+0x5c/0x10c  rpm_resume+0xe0/0x52c  rpm_resume+0x178/0x52c  __pm_runtime_resume+0x58/0x98  clk_pm_runtime_get+0x30/0xb0  clk_disable_unused_subtree+0x58/0x208  clk_disable_unused_subtree+0x38/0x208  clk_disable_unused_subtree+0x38/0x208  clk_disable_unused_subtree+0x38/0x208  clk_disable_unused_subtree+0x38/0x208  clk_disable_unused+0x4c/0xe4  do_one_initcall+0xcc/0x2d8  do_initcall_level+0xa4/0x148  do_initcalls+0x5c/0x9c  do_basic_setup+0x24/0x30  kernel_init_freeable+0xec/0x164  kernel_init+0x28/0x120  ret_from_fork+0x10/0x20 INFO: task kworker/u16:0:9 blocked for more than 122 seconds.       Not tainted 5.15.149-21875-gf795ebc40eb8 #1 &#34;echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs&#34; disables this message. task:kworker/u16:0   state:D stack:    0 pid:    9 ppid:     2 flags:0x00000008 Workqueue: events_unbound deferred_probe_work_func Call trace:  __switch_to+0xf4/0x1f4  __schedule+0x418/0xb80  schedule+0x5c/0x10c  schedule_preempt_disabled+0x2c/0x48  __mutex_lock+0x238/0x488  __mutex_lock_slowpath+0x1c/0x28  mutex_lock+0x50/0x74  clk_prepare_lock+0x7c/0x9c  clk_core_prepare_lock+0x20/0x44  clk_prepare+0x24/0x30  clk_bulk_prepare+0x40/0xb0  mdss_runtime_resume+0x54/0x1c8  pm_generic_runtime_resume+0x30/0x44  __genpd_runtime_resume+0x68/0x7c  genpd_runtime_resume+0x108/0x1f4  __rpm_callback+0x84/0x144  rpm_callback+0x30/0x88  rpm_resume+0x1f4/0x52c  rpm_resume+0x178/0x52c  __pm_runtime_resume+0x58/0x98  __device_attach+0xe0/0x170  device_initial_probe+0x1c/0x28  bus_probe_device+0x3c/0x9c  device_add+0x644/0x814  mipi_dsi_device_register_full+0xe4/0x170  devm_mipi_dsi_device_register_full+0x28/0x70  ti_sn_bridge_probe+0x1dc/0x2c0  auxiliary_bus_probe+0x4c/0x94  really_probe+0xcc/0x2c8  __driver_probe_device+0xa8/0x130  driver_probe_device+0x48/0x110  __device_attach_driver+0xa4/0xcc  bus_for_each_drv+0x8c/0xd8  __device_attach+0xf8/0x170  device_initial_probe+0x1c/0x28  bus_probe_device+0x3c/0x9c  deferred_probe_work_func+0x9c/0xd8  process_one_work+0x148/0x518  worker_thread+0x138/0x350  kthread+0x138/0x1e0  ret_from_fork+0x10/0x20The first thread is walking the clk tree and callingclk_pm_runtime_get() to power on devices required to read the clkhardware via struct clk_ops::is_enabled(). This thread holds the clkprepare_lock, and is trying to runtime PM resume a device, when it findsthat the device is in the process of resuming so the thread schedule()saway waiting for the device to finish resuming before continuing. Thesecond thread is runtime PM resuming the same device, but the runtimeresume callback is calling clk_prepare(), trying to grab theprepare_lock waiting on the first thread.This is a classic ABBA deadlock. To properly fix the deadlock, we mustnever runtime PM resume or suspend a device with the clk prepare_lockheld. Actually doing that is near impossible today because the globalprepare_lock would have to be dropped in the middle of the tree, thedevice runtime PM resumed/suspended, and then the prepare_lock grabbedagain to ensure consistency of the clk tree topology. If anythingchanges with the clk tree in the meantime, we&#39;ve lost and will need tostart the operation all over again.Luckily, most of the time we&#39;re simply incrementing or decrementing theruntime PM count on an active device, so we don&#39;t have the chance toschedule away with the prepare_lock held. Let&#39;s fix this immediateproblem that can be---truncated---(CVE-2024-27004)In the Linux kernel, the following vulnerability has been resolved:fpga: bridge: add owner module and take its refcountThe current implementation of the fpga bridge assumes that the low-levelmodule registers a driver for the parent device and uses its owner pointerto take the module&#39;s refcount. This approach is problematic since it canlead to a null pointer dereference while attempting to get the bridge ifthe parent device does not have a driver.To address this problem, add a module owner pointer to the fpga_bridgestruct and use it to take the module&#39;s refcount. Modify the function forregistering a bridge to take an additional owner module parameter andrename it to avoid conflicts. Use the old function name for a helper macrothat automatically sets the module that registers the bridge as the owner.This ensures compatibility with existing low-level control modules andreduces the chances of registering a bridge without setting the owner.Also, update the documentation to keep it consistent with the new interfacefor registering an fpga bridge.Other changes: opportunistically move put_device() from __fpga_bridge_get()to fpga_bridge_get() and of_fpga_bridge_get() to improve code clarity sincethe bridge device is taken in these functions.(CVE-2024-36479)In the Linux kernel, the following vulnerability has been resolved:fpga: manager: add owner module and take its refcountThe current implementation of the fpga manager assumes that the low-levelmodule registers a driver for the parent device and uses its owner pointerto take the module&#39;s refcount. This approach is problematic since it canlead to a null pointer dereference while attempting to get the manager ifthe parent device does not have a driver.To address this problem, add a module owner pointer to the fpga_managerstruct and use it to take the module&#39;s refcount. Modify the functions forregistering the manager to take an additional owner module parameter andrename them to avoid conflicts. Use the old function names for helpermacros that automatically set the module that registers the manager as theowner. This ensures compatibility with existing low-level control modulesand reduces the chances of registering a manager without setting the owner.Also, update the documentation to keep it consistent with the new interfacefor registering an fpga manager.Other changes: opportunistically move put_device() from __fpga_mgr_get() tofpga_mgr_get() and of_fpga_mgr_get() to improve code clarity since themanager device is taken in these functions.(CVE-2024-37021)In the Linux kernel, the following vulnerability has been resolved:i2c: lpi2c: Avoid calling clk_get_rate during transferInstead of repeatedly calling clk_get_rate for each transfer, lockthe clock rate and cache the value.A deadlock has been observed while adding tlv320aic32x4 audio codec tothe system. When this clock provider adds its clock, the clk mutex islocked already, it needs to access i2c, which in return needs the mutexfor clk_get_rate as well.(CVE-2024-40965)In the Linux kernel, the following vulnerability has been resolved:arm64: probes: Fix uprobes for big-endian kernelsThe arm64 uprobes code is broken for big-endian kernels as it doesn&#39;tconvert the in-memory instruction encoding (which is alwayslittle-endian) into the kernel&#39;s native endianness before analyzing andsimulating instructions. This may result in a few distinct problems:* The kernel may may erroneously reject probing an instruction which can  safely be probed.* The kernel may erroneously erroneously permit stepping an  instruction out-of-line when that instruction cannot be stepped  out-of-line safely.* The kernel may erroneously simulate instruction incorrectly dur to  interpretting the byte-swapped encoding.The endianness mismatch isn&#39;t caught by the compiler or sparse because:* The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so  the compiler and sparse have no idea these contain a little-endian  32-bit value. The core uprobes code populates these with a memcpy()  which similarly does not handle endianness.* While the uprobe_opcode_t type is an alias for __le32, both  arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[]  to the similarly-named probe_opcode_t, which is an alias for u32.  Hence there is no endianness conversion warning.Fix this by changing the arch_uprobe::{insn,ixol} fields to __le32 andadding the appropriate __le32_to_cpu() conversions prior to consumingthe instruction encoding. The core uprobes copies these fields as opaqueranges of bytes, and so is unaffected by this change.At the same time, remove MAX_UINSN_BYTES and consistently useAARCH64_INSN_SIZE for clarity.Tested with the following:| #include &lt;stdio.h&gt;| #include &lt;stdbool.h&gt;|| #define noinline __attribute__((noinline))|| static noinline void *adrp_self(void)| {|         void *addr;||         asm volatile(|         &#34;       adrp    %x0, adrp_self\n&#34;|         &#34;       add     %x0, %x0, :lo12:adrp_self\n&#34;|         : &#34;=r&#34; (addr));| }||| int main(int argc, char *argv)| {|         void *ptr = adrp_self();|         bool equal = (ptr == adrp_self);||         printf(&#34;adrp_self   =&gt; %p\n&#34;|                &#34;adrp_self() =&gt; %p\n&#34;|                &#34;%s\n&#34;,|                adrp_self, ptr, equal ? &#34;EQUAL&#34; : &#34;NOT EQUAL&#34;);||         return 0;| }.... where the adrp_self() function was compiled to:| 00000000004007e0 &lt;adrp_self&gt;:|   4007e0:       90000000        adrp    x0, 400000 &lt;__ehdr_start&gt;|   4007e4:       911f8000        add     x0, x0, #0x7e0|   4007e8:       d65f03c0        retBefore this patch, the ADRP is not recognized, and is assumed to besteppable, resulting in corruption of the result:| # ./adrp-self| adrp_self   =&gt; 0x4007e0| adrp_self() =&gt; 0x4007e0| EQUAL| # echo &#39;p /root/adrp-self:0x007e0&#39; &gt; /sys/kernel/tracing/uprobe_events| # echo 1 &gt; /sys/kernel/tracing/events/uprobes/enable| # ./adrp-self| adrp_self   =&gt; 0x4007e0| adrp_self() =&gt; 0xffffffffff7e0| NOT EQUALAfter this patch, the ADRP is correctly recognized and simulated:| # ./adrp-self| adrp_self   =&gt; 0x4007e0| adrp_self() =&gt; 0x4007e0| EQUAL| #| # echo &#39;p /root/adrp-self:0x007e0&#39; &gt; /sys/kernel/tracing/uprobe_events| # echo 1 &gt; /sys/kernel/tracing/events/uprobes/enable| # ./adrp-self| adrp_self   =&gt; 0x4007e0| adrp_self() =&gt; 0x4007e0| EQUAL(CVE-2024-50194)In the Linux kernel, the following vulnerability has been resolved:dm cache: fix flushing uninitialized delayed_work on cache_ctr errorAn unexpected WARN_ON from flush_work() may occur when cache creationfails, caused by destroying the uninitialized delayed_work waker in theerror path of cache_create(). For example, the warning appears on thesuperblock checksum error.Reproduce steps:dmsetup create cmeta --table &#34;0 8192 linear /dev/sdc 0&#34;dmsetup create cdata --table &#34;0 65536 linear /dev/sdc 8192&#34;dmsetup create corig --table &#34;0 524288 linear /dev/sdc 262144&#34;dd if=/dev/urandom of=/dev/mapper/cmeta bs=4k count=1 oflag=directdmsetup create cache --table &#34;0 524288 cache /dev/mapper/cmeta \/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0&#34;Kernel logs:(snip)WARNING: CPU: 0 PID: 84 at kernel/workqueue.c:4178 __flush_work+0x5d4/0x890Fix by pulling out the cancel_delayed_work_sync() from the constructor&#39;serror path. This patch doesn&#39;t affect the use-after-free fix forconcurrent dm_resume and dm_destroy (commit 6a459d8edbdb (&#34;dm cache: FixUAF in destroy()&#34;)) as cache_dtr is not changed.(CVE-2024-50280)In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix null-ptr-deref in block_touch_buffer tracepointPatch series &#34;nilfs2: fix null-ptr-deref bugs on block tracepoints&#34;.This series fixes null pointer dereference bugs that occur when usingnilfs2 and two block-related tracepoints.This patch (of 2):It has been reported that when using &#34;block:block_touch_buffer&#34;tracepoint, touch_buffer() called from __nilfs_get_folio_block() causes aNULL pointer dereference, or a general protection fault when KASAN isenabled.This happens because since the tracepoint was added in touch_buffer(), itreferences the dev_t member bh-&gt;b_bdev-&gt;bd_dev regardless of whether thebuffer head has a pointer to a block_device structure.  In the currentimplementation, the block_device structure is set after the functionreturns to the caller.Here, touch_buffer() is used to mark the folio/page that owns the bufferhead as accessed, but the common search helper for folio/page used by thecaller function was optimized to mark the folio/page as accessed when itwas reimplemented a long time ago, eliminating the need to calltouch_buffer() here in the first place.So this solves the issue by eliminating the touch_buffer() call itself.(CVE-2024-53131)In the Linux kernel, the following vulnerability has been resolved:um: net: Do not use drvdata in releaseThe drvdata is not available in release. Let&#39;s just use container_of()to get the uml_net instance. Otherwise, removing a network device willresult in a crash:RIP: 0033:net_device_release+0x10/0x6fRSP: 00000000e20c7c40  EFLAGS: 00010206RAX: 000000006002e4e7 RBX: 00000000600f1baf RCX: 00000000624074e0RDX: 0000000062778000 RSI: 0000000060551c80 RDI: 00000000627af028RBP: 00000000e20c7c50 R08: 00000000603ad594 R09: 00000000e20c7b70R10: 000000000000135a R11: 00000000603ad422 R12: 0000000000000000R13: 0000000062c7af00 R14: 0000000062406d60 R15: 00000000627700b6Kernel panic - not syncing: Segfault with no mmCPU: 0 UID: 0 PID: 29 Comm: kworker/0:2 Not tainted 6.12.0-rc6-g59b723cd2adb #1Workqueue: events mc_work_procStack: 627af028 62c7af00 e20c7c80 60276fcd 62778000 603f5820 627af028 00000000 e20c7cb0 603a2bcd 627af000 62770010Call Trace: [&lt;60276fcd&gt;] device_release+0x70/0xba [&lt;603a2bcd&gt;] kobject_put+0xba/0xe7 [&lt;60277265&gt;] put_device+0x19/0x1c [&lt;60281266&gt;] platform_device_put+0x26/0x29 [&lt;60281e5f&gt;] platform_device_unregister+0x2c/0x2e [&lt;6002ec9c&gt;] net_remove+0x63/0x69 [&lt;60031316&gt;] ? mconsole_reply+0x0/0x50 [&lt;600310c8&gt;] mconsole_remove+0x160/0x1cc [&lt;60087d40&gt;] ? __remove_hrtimer+0x38/0x74 [&lt;60087ff8&gt;] ? hrtimer_try_to_cancel+0x8c/0x98 [&lt;6006b3cf&gt;] ? dl_server_stop+0x3f/0x48 [&lt;6006b390&gt;] ? dl_server_stop+0x0/0x48 [&lt;600672e8&gt;] ? dequeue_entities+0x327/0x390 [&lt;60038fa6&gt;] ? um_set_signals+0x0/0x43 [&lt;6003070c&gt;] mc_work_proc+0x77/0x91 [&lt;60057664&gt;] process_scheduled_works+0x1b3/0x2dd [&lt;60055f32&gt;] ? assign_work+0x0/0x58 [&lt;60057f0a&gt;] worker_thread+0x1e9/0x293 [&lt;6005406f&gt;] ? set_pf_worker+0x0/0x64 [&lt;6005d65d&gt;] ? arch_local_irq_save+0x0/0x2d [&lt;6005d748&gt;] ? kthread_exit+0x0/0x3a [&lt;60057d21&gt;] ? worker_thread+0x0/0x293 [&lt;6005dbf1&gt;] kthread+0x126/0x12b [&lt;600219c5&gt;] new_thread_handler+0x85/0xb6(CVE-2024-53183)In the Linux kernel, the following vulnerability has been resolved:xen: Fix the issue of resource not being properly released in xenbus_dev_probe()This patch fixes an issue in the function xenbus_dev_probe(). In thexenbus_dev_probe() function, within the if (err) branch at line 313, theprogram incorrectly returns err directly without releasing the resourcesallocated by err = drv-&gt;probe(dev, id). As the return value is non-zero,the upper layers assume the processing logic has failed. However, the probeoperation was performed earlier without a corresponding remove operation.Since the probe actually allocates resources, failing to perform the removeoperation could lead to problems.To fix this issue, we followed the resource release logic of thexenbus_dev_remove() function by adding a new block fail_remove before thefail_put block. After entering the branch if (err) at line 313, thefunction will use a goto statement to jump to the fail_remove block,ensuring that the previously acquired resources are correctly released,thus preventing the reference count leak.This bug was identified by an experimental static analysis tool developedby our team. The tool specializes in analyzing reference count operationsand detecting potential issues where resources are not properly managed.In this case, the tool flagged the missing release operation as apotential problem, which led to the development of this patch.(CVE-2024-53198)In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix null check for pipe_ctx-&gt;plane_state in dcn20_program_pipeThis commit addresses a null pointer dereference issue indcn20_program_pipe(). Previously, commit 8e4ed3cf1642 ( drm/amd/display:Add null check for pipe_ctx-&gt;plane_state in dcn20_program_pipe )partially fixed the null pointer dereference issue. However, indcn20_update_dchubp_dpp(), the variable pipe_ctx is passed in, andplane_state is accessed again through pipe_ctx. Multiple if statementsdirectly call attributes of plane_state, leading to potential nullpointer dereference issues. This patch adds necessary null checks toensure stability.(CVE-2024-53201)In the Linux kernel, the following vulnerability has been resolved:wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_config_scan()Replace one-element array with a flexible-array member in `structmwifiex_ie_types_wildcard_ssid_params` to fix the following warningon a MT8173 Chromebook (mt8173-elm-hana):[  356.775250] ------------[ cut here ]------------[  356.784543] memcpy: detected field-spanning write (size 6) of single field &#34;wildcard_ssid_tlv-&gt;ssid&#34; at drivers/net/wireless/marvell/mwifiex/scan.c:904 (size 1)[  356.813403] WARNING: CPU: 3 PID: 742 at drivers/net/wireless/marvell/mwifiex/scan.c:904 mwifiex_scan_networks+0x4fc/0xf28 [mwifiex]The &#34;(size 6)&#34; above is exactly the length of the SSID of the networkthis device was connected to. The source of the warning looks like:    ssid_len = user_scan_in-&gt;ssid_list[i].ssid_len;    [...]    memcpy(wildcard_ssid_tlv-&gt;ssid,           user_scan_in-&gt;ssid_list[i].ssid, ssid_len);There is a #define WILDCARD_SSID_TLV_MAX_SIZE that uses sizeof() on thisstruct, but it already didn&#39;t account for the size of the one-elementarray, so it doesn&#39;t need to be changed.(CVE-2024-56539)In the Linux kernel, the following vulnerability has been resolved:media: uvcvideo: Require entities to have a non-zero unique IDPer UVC 1.1+ specification 3.7.2, units and terminals must have a non-zerounique ID.```Each Unit and Terminal within the video function is assigned a uniqueidentification number, the Unit ID (UID) or Terminal ID (TID), contained inthe bUnitID or bTerminalID field of the descriptor. The value 0x00 isreserved for undefined ID,```So, deny allocating an entity with ID 0 or an ID that belongs to a unitthat is already added to the list of entities.This also prevents some syzkaller reproducers from triggering warnings dueto a chain of entities referring to themselves. In one particular case, anOutput Unit is connected to an Input Unit, both with the same ID of 1. Butwhen looking up for the source ID of the Output Unit, that same entity isfound instead of the input entity, which leads to such warnings.In another case, a backward chain was considered finished as the source IDwas 0. Later on, that entity was found, but its pads were not valid.Here is a sample stack trace for one of those cases.[   20.650953] usb 1-1: new high-speed USB device number 2 using dummy_hcd[   20.830206] usb 1-1: Using ep0 maxpacket: 8[   20.833501] usb 1-1: config 0 descriptor??[   21.038518] usb 1-1: string descriptor 0 read error: -71[   21.038893] usb 1-1: Found UVC 0.00 device &lt;unnamed&gt; (2833:0201)[   21.039299] uvcvideo 1-1:0.0: Entity type for entity Output 1 was not initialized![   21.041583] uvcvideo 1-1:0.0: Entity type for entity Input 1 was not initialized![   21.042218] ------------[ cut here ]------------[   21.042536] WARNING: CPU: 0 PID: 9 at drivers/media/mc/mc-entity.c:1147 media_create_pad_link+0x2c4/0x2e0[   21.043195] Modules linked in:[   21.043535] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Not tainted 6.11.0-rc7-00030-g3480e43aeccf #444[   21.044101] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014[   21.044639] Workqueue: usb_hub_wq hub_event[   21.045100] RIP: 0010:media_create_pad_link+0x2c4/0x2e0[   21.045508] Code: fe e8 20 01 00 00 b8 f4 ff ff ff 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 0f 0b eb e9 0f 0b eb 0a 0f 0b eb 06 &lt;0f&gt; 0b eb 02 0f 0b b8 ea ff ff ff eb d4 66 2e 0f 1f 84 00 00 00 00[   21.046801] RSP: 0018:ffffc9000004b318 EFLAGS: 00010246[   21.047227] RAX: ffff888004e5d458 RBX: 0000000000000000 RCX: ffffffff818fccf1[   21.047719] RDX: 000000000000007b RSI: 0000000000000000 RDI: ffff888004313290[   21.048241] RBP: ffff888004313290 R08: 0001ffffffffffff R09: 0000000000000000[   21.048701] R10: 0000000000000013 R11: 0001888004313290 R12: 0000000000000003[   21.049138] R13: ffff888004313080 R14: ffff888004313080 R15: 0000000000000000[   21.049648] FS:  0000000000000000(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000[   21.050271] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033[   21.050688] CR2: 0000592cc27635b0 CR3: 000000000431c000 CR4: 0000000000750ef0[   21.051136] PKRU: 55555554[   21.051331] Call Trace:[   21.051480]  &lt;TASK&gt;[   21.051611]  ? __warn+0xc4/0x210[   21.051861]  ? media_create_pad_link+0x2c4/0x2e0[   21.052252]  ? report_bug+0x11b/0x1a0[   21.052540]  ? trace_hardirqs_on+0x31/0x40[   21.052901]  ? handle_bug+0x3d/0x70[   21.053197]  ? exc_invalid_op+0x1a/0x50[   21.053511]  ? asm_exc_invalid_op+0x1a/0x20[   21.053924]  ? media_create_pad_link+0x91/0x2e0[   21.054364]  ? media_create_pad_link+0x2c4/0x2e0[   21.054834]  ? media_create_pad_link+0x91/0x2e0[   21.055131]  ? _raw_spin_unlock+0x1e/0x40[   21.055441]  ? __v4l2_device_register_subdev+0x202/0x210[   21.055837]  uvc_mc_register_entities+0x358/0x400[   21.056144]  uvc_register_chains+0x1fd/0x290[   21.056413]  uvc_probe+0x380e/0x3dc0[   21.056676]  ? __lock_acquire+0x5aa/0x26e0[   21.056946]  ? find_held_lock+0x33/0xa0[   21.057196]  ? kernfs_activate+0x70/0x80[   21.057533]  ? usb_match_dy---truncated---(CVE-2024-56571)In the Linux kernel, the following vulnerability has been resolved:scsi: hisi_sas: Create all dump files during debugfs initializationFor the current debugfs of hisi_sas, after user triggers dump, thedriver allocate memory space to save the register information and createdebugfs files to display the saved information. In this process, thedebugfs files created after each dump.Therefore, when the dump is triggered while the driver is unbind, thefollowing hang occurs:[67840.853907] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0[67840.862947] Mem abort info:[67840.865855]   ESR = 0x0000000096000004[67840.869713]   EC = 0x25: DABT (current EL), IL = 32 bits[67840.875125]   SET = 0, FnV = 0[67840.878291]   EA = 0, S1PTW = 0[67840.881545]   FSC = 0x04: level 0 translation fault[67840.886528] Data abort info:[67840.889524]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000[67840.895117]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0[67840.900284]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0[67840.905709] user pgtable: 4k pages, 48-bit VAs, pgdp=0000002803a1f000[67840.912263] [00000000000000a0] pgd=0000000000000000, p4d=0000000000000000[67840.919177] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP[67840.996435] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)[67841.003628] pc : down_write+0x30/0x98[67841.007546] lr : start_creating.part.0+0x60/0x198[67841.012495] sp : ffff8000b979ba20[67841.016046] x29: ffff8000b979ba20 x28: 0000000000000010 x27: 0000000000024b40[67841.023412] x26: 0000000000000012 x25: ffff20202b355ae8 x24: ffff20202b35a8c8[67841.030779] x23: ffffa36877928208 x22: ffffa368b4972240 x21: ffff8000b979bb18[67841.038147] x20: ffff00281dc1e3c0 x19: fffffffffffffffe x18: 0000000000000020[67841.045515] x17: 0000000000000000 x16: ffffa368b128a530 x15: ffffffffffffffff[67841.052888] x14: ffff8000b979bc18 x13: ffffffffffffffff x12: ffff8000b979bb18[67841.060263] x11: 0000000000000000 x10: 0000000000000000 x9 : ffffa368b1289b18[67841.067640] x8 : 0000000000000012 x7 : 0000000000000000 x6 : 00000000000003a9[67841.075014] x5 : 0000000000000000 x4 : ffff002818c5cb00 x3 : 0000000000000001[67841.082388] x2 : 0000000000000000 x1 : ffff002818c5cb00 x0 : 00000000000000a0[67841.089759] Call trace:[67841.092456]  down_write+0x30/0x98[67841.096017]  start_creating.part.0+0x60/0x198[67841.100613]  debugfs_create_dir+0x48/0x1f8[67841.104950]  debugfs_create_files_v3_hw+0x88/0x348 [hisi_sas_v3_hw][67841.111447]  debugfs_snapshot_regs_v3_hw+0x708/0x798 [hisi_sas_v3_hw][67841.118111]  debugfs_trigger_dump_v3_hw_write+0x9c/0x120 [hisi_sas_v3_hw][67841.125115]  full_proxy_write+0x68/0xc8[67841.129175]  vfs_write+0xd8/0x3f0[67841.132708]  ksys_write+0x70/0x108[67841.136317]  __arm64_sys_write+0x24/0x38[67841.140440]  invoke_syscall+0x50/0x128[67841.144385]  el0_svc_common.constprop.0+0xc8/0xf0[67841.149273]  do_el0_svc+0x24/0x38[67841.152773]  el0_svc+0x38/0xd8[67841.156009]  el0t_64_sync_handler+0xc0/0xc8[67841.160361]  el0t_64_sync+0x1a4/0x1a8[67841.164189] Code: b9000882 d2800002 d2800023 f9800011 (c85ffc05)[67841.170443] ---[ end trace 0000000000000000 ]---To fix this issue, create all directories and files during debugfsinitialization. In this way, the driver only needs to allocate memoryspace to save information each time the user triggers dumping.(CVE-2024-56588)In the Linux kernel, the following vulnerability has been resolved:kcsan: Turn report_filterlist_lock into a raw_spinlockRan Xiaokai reports that with a KCSAN-enabled PREEMPT_RT kernel, we can seesplats like:| BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48| in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1| preempt_count: 10002, expected: 0| RCU nest depth: 0, expected: 0| no locks held by swapper/1/0.| irq event stamp: 156674| hardirqs last  enabled at (156673): [&lt;ffffffff81130bd9&gt;] do_idle+0x1f9/0x240| hardirqs last disabled at (156674): [&lt;ffffffff82254f84&gt;] sysvec_apic_timer_interrupt+0x14/0xc0| softirqs last  enabled at (0): [&lt;ffffffff81099f47&gt;] copy_process+0xfc7/0x4b60| softirqs last disabled at (0): [&lt;0000000000000000&gt;] 0x0| Preemption disabled at:| [&lt;ffffffff814a3e2a&gt;] paint_ptr+0x2a/0x90| CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 6.11.0+ #3| Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014| Call Trace:|  &lt;IRQ&gt;|  dump_stack_lvl+0x7e/0xc0|  dump_stack+0x1d/0x30|  __might_resched+0x1a2/0x270|  rt_spin_lock+0x68/0x170|  kcsan_skip_report_debugfs+0x43/0xe0|  print_report+0xb5/0x590|  kcsan_report_known_origin+0x1b1/0x1d0|  kcsan_setup_watchpoint+0x348/0x650|  __tsan_unaligned_write1+0x16d/0x1d0|  hrtimer_interrupt+0x3d6/0x430|  __sysvec_apic_timer_interrupt+0xe8/0x3a0|  sysvec_apic_timer_interrupt+0x97/0xc0|  &lt;/IRQ&gt;On a detected data race, KCSAN&#39;s reporting logic checks if it shouldfilter the report. That list is protected by the report_filterlist_lock*non-raw* spinlock which may sleep on RT kernels.Since KCSAN may report data races in any context, convert it to araw_spinlock.This requires being careful about when to allocate memory for the filterlist itself which can be done via KCSAN&#39;s debugfs interface. Concurrentmodification of the filter list via debugfs should be rare: the chosenstrategy is to optimistically pre-allocate memory before the criticalsection and discard if unused.(CVE-2024-56610)In the Linux kernel, the following vulnerability has been resolved:mm/mempolicy: fix migrate_to_node() assuming there is at least one VMA in a MMWe currently assume that there is at least one VMA in a MM, which isn&#39;ttrue.So we might end up having find_vma() return NULL, to then de-referenceNULL.  So properly handle find_vma() returning NULL.This fixes the report: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 UID: 0 PID: 6021 Comm: syz-executor284 Not tainted 6.12.0-rc7-syzkaller-00187-gf868cd251776 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024RIP: 0010:migrate_to_node mm/mempolicy.c:1090 [inline]RIP: 0010:do_migrate_pages+0x403/0x6f0 mm/mempolicy.c:1194Code: ...RSP: 0018:ffffc9000375fd08 EFLAGS: 00010246RAX: 0000000000000000 RBX: ffffc9000375fd78 RCX: 0000000000000000RDX: ffff88807e171300 RSI: dffffc0000000000 RDI: ffff88803390c044RBP: ffff88807e171428 R08: 0000000000000014 R09: fffffbfff2039ef1R10: ffffffff901cf78f R11: 0000000000000000 R12: 0000000000000003R13: ffffc9000375fe90 R14: ffffc9000375fe98 R15: ffffc9000375fdf8FS:  00005555919e1380(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00005555919e1ca8 CR3: 000000007f12a000 CR4: 00000000003526f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: &lt;TASK&gt; kernel_migrate_pages+0x5b2/0x750 mm/mempolicy.c:1709 __do_sys_migrate_pages mm/mempolicy.c:1727 [inline] __se_sys_migrate_pages mm/mempolicy.c:1723 [inline] __x64_sys_migrate_pages+0x96/0x100 mm/mempolicy.c:1723 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[akpm@linux-foundation.org: add unlikely()](CVE-2024-56611)In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Fix use after free on unloadSystem crash is observed with stack trace warning of use afterfree. There are 2 signals to tell dpc_thread to terminate (UNLOADINGflag and kthread_stop).On setting the UNLOADING flag when dpc_thread happens to run at the timeand sees the flag, this causes dpc_thread to exit and clean upitself. When kthread_stop is called for final cleanup, this causes useafter free.Remove UNLOADING signal to terminate dpc_thread.  Use the kthread_stopas the main signal to exit dpc_thread.[596663.812935] kernel BUG at mm/slub.c:294![596663.812950] invalid opcode: 0000 [#1] SMP PTI[596663.812957] CPU: 13 PID: 1475935 Comm: rmmod Kdump: loaded Tainted: G          IOE    --------- -  - 4.18.0-240.el8.x86_64 #1[596663.812960] Hardware name: HP ProLiant DL380p Gen8, BIOS P70 08/20/2012[596663.812974] RIP: 0010:__slab_free+0x17d/0x360...[596663.813008] Call Trace:[596663.813022]  ? __dentry_kill+0x121/0x170[596663.813030]  ? _cond_resched+0x15/0x30[596663.813034]  ? _cond_resched+0x15/0x30[596663.813039]  ? wait_for_completion+0x35/0x190[596663.813048]  ? try_to_wake_up+0x63/0x540[596663.813055]  free_task+0x5a/0x60[596663.813061]  kthread_stop+0xf3/0x100[596663.813103]  qla2x00_remove_one+0x284/0x440 [qla2xxx](CVE-2024-56623)In the Linux kernel, the following vulnerability has been resolved:sunrpc: clear XPRT_SOCK_UPD_TIMEOUT when reset transportSince transport-&gt;sock has been set to NULL during reset transport,XPRT_SOCK_UPD_TIMEOUT also needs to be cleared. Otherwise, thexs_tcp_set_socket_timeouts() may be triggered in xs_tcp_send_request()to dereference the transport-&gt;sock that has been set to NULL.(CVE-2024-56688)In the Linux kernel, the following vulnerability has been resolved:9p/xen: fix release of IRQKernel logs indicate an IRQ was double-freed.Pass correct device ID during IRQ release.[Dominique: remove confusing variable reset to 0](CVE-2024-56704)In the Linux kernel, the following vulnerability has been resolved:ionic: Fix netdev notifier unregister on failureIf register_netdev() fails, then the driver leaks the netdev notifier.Fix this by calling ionic_lif_unregister() on register_netdev()failure. This will also call ionic_lif_unregister_phc() if it hasalready been registered.(CVE-2024-56715)In the Linux kernel, the following vulnerability has been resolved:fbdev: sh7760fb: Fix a possible memory leak in sh7760fb_alloc_mem()When information such as info-&gt;screen_base is not ready, callingsh7760fb_free_mem() does not release memory correctly. Calldma_free_coherent() instead.(CVE-2024-56746)In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix slab-use-after-free due to dangling pointer dqi_privWhen mounting ocfs2 and then remounting it as read-only, aslab-use-after-free occurs after the user uses a syscall toquota_getnextquota.  Specifically, sb_dqinfo(sb, type)-&gt;dqi_priv is thedangling pointer.During the remounting process, the pointer dqi_priv is freed but is neverset as null leaving it to be accessed.  Additionally, the read-only optionfor remounting sets the DQUOT_SUSPENDED flag instead of setting theDQUOT_USAGE_ENABLED flags.  Moreover, later in the process of getting thenext quota, the function ocfs2_get_next_id is called and only checks thequota usage flags and not the quota suspended flags.To fix this, I set dqi_priv to null when it is freed after remounting withread-only and put a check for DQUOT_SUSPENDED in ocfs2_get_next_id.[akpm@linux-foundation.org: coding-style cleanups](CVE-2024-57892)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="bpftool" release="248.0.0.147.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="248.0.0.147.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="248.0.0.147.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="248.0.0.147.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="248.0.0.147.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="248.0.0.147.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="248.0.0.147.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="248.0.0.147.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="248.0.0.147.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="248.0.0.147.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="248.0.0.147.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="248.0.0.147.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="248.0.0.147.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="248.0.0.147.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="248.0.0.147.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="248.0.0.147.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="248.0.0.147.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="248.0.0.147.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="248.0.0.147.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="248.0.0.147.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="248.0.0.147.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="248.0.0.147.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="248.0.0.147.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="248.0.0.147.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="248.0.0.147.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="248.0.0.147.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="248.0.0.147.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="248.0.0.147.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="248.0.0.147.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="248.0.0.147.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1099</id>
          <title>An update for binutils is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-02-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57360" id="CVE-2024-57360" title="CVE-2024-57360" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-0840" id="CVE-2025-0840" title="CVE-2025-0840" type="cve"></reference>
          </references>
          <description>https://www.gnu.org/software/binutils/ nm &gt;=2.43 is affected by: Incorrect Access Control. The type of exploitation is: local. The component is: `nm --without-symbol-version` function.(CVE-2024-57360)A vulnerability, which was classified as problematic, was found in GNU Binutils up to 2.43. This affects the function disassemble_bytes of the file binutils/objdump.c. The manipulation of the argument buf leads to stack-based buffer overflow. It is possible to initiate the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. Upgrading to version 2.44 is able to address this issue. The identifier of the patch is baac6c221e9d69335bf41366a1c7d87d8ab2f893. It is recommended to upgrade the affected component.(CVE-2025-0840)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="binutils" release="30.oe2203sp4" version="2.37">
                         <filename>binutils-2.37-30.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="binutils-debuginfo" release="30.oe2203sp4" version="2.37">
                         <filename>binutils-debuginfo-2.37-30.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="binutils-debugsource" release="30.oe2203sp4" version="2.37">
                         <filename>binutils-debugsource-2.37-30.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="binutils-devel" release="30.oe2203sp4" version="2.37">
                         <filename>binutils-devel-2.37-30.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="binutils-help" release="30.oe2203sp4" version="2.37">
                         <filename>binutils-help-2.37-30.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="binutils" release="30.oe2203sp4" version="2.37">
                         <filename>binutils-2.37-30.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="binutils-debuginfo" release="30.oe2203sp4" version="2.37">
                         <filename>binutils-debuginfo-2.37-30.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="binutils-debugsource" release="30.oe2203sp4" version="2.37">
                         <filename>binutils-debugsource-2.37-30.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="binutils-devel" release="30.oe2203sp4" version="2.37">
                         <filename>binutils-devel-2.37-30.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="binutils-help" release="30.oe2203sp4" version="2.37">
                         <filename>binutils-help-2.37-30.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1103</id>
          <title>An update for mysql is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-02-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21490" id="CVE-2025-21490" title="CVE-2025-21490" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21491" id="CVE-2025-21491" title="CVE-2025-21491" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21495" id="CVE-2025-21495" title="CVE-2025-21495" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21497" id="CVE-2025-21497" title="CVE-2025-21497" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21500" id="CVE-2025-21500" title="CVE-2025-21500" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21501" id="CVE-2025-21501" title="CVE-2025-21501" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21503" id="CVE-2025-21503" title="CVE-2025-21503" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21505" id="CVE-2025-21505" title="CVE-2025-21505" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21518" id="CVE-2025-21518" title="CVE-2025-21518" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21519" id="CVE-2025-21519" title="CVE-2025-21519" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21520" id="CVE-2025-21520" title="CVE-2025-21520" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21522" id="CVE-2025-21522" title="CVE-2025-21522" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21523" id="CVE-2025-21523" title="CVE-2025-21523" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21529" id="CVE-2025-21529" title="CVE-2025-21529" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21531" id="CVE-2025-21531" title="CVE-2025-21531" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21540" id="CVE-2025-21540" title="CVE-2025-21540" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21543" id="CVE-2025-21543" title="CVE-2025-21543" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21546" id="CVE-2025-21546" title="CVE-2025-21546" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21555" id="CVE-2025-21555" title="CVE-2025-21555" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21559" id="CVE-2025-21559" title="CVE-2025-21559" type="cve"></reference>
          </references>
          <description>Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.40 and prior, 8.4.3 and prior and  9.1.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).(CVE-2025-21490)Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.40 and prior, 8.4.3 and prior and  9.1.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).(CVE-2025-21491)Vulnerability in the MySQL Enterprise Firewall product of Oracle MySQL (component: Firewall).  Supported versions that are affected are 8.0.40 and prior, 8.4.3 and prior and  9.1.0 and prior. Difficult to exploit vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Enterprise Firewall.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Enterprise Firewall. CVSS 3.1 Base Score 4.4 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H).(CVE-2025-21495)Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.40 and prior, 8.4.3 and prior and  9.1.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server as well as  unauthorized update, insert or delete access to some of MySQL Server accessible data. CVSS 3.1 Base Score 5.5 (Integrity and Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:H).(CVE-2025-21497)Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.40 and prior, 8.4.3 and prior and  9.1.0 and prior. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).(CVE-2025-21500)Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.40 and prior, 8.4.3 and prior and  9.1.0 and prior. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).(CVE-2025-21501)Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.40 and prior, 8.4.3 and prior and  9.1.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).(CVE-2025-21503)Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Components Services).  Supported versions that are affected are 8.0.40 and prior, 8.4.3 and prior and  9.1.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).(CVE-2025-21505)Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.40 and prior, 8.4.3 and prior and  9.1.0 and prior. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).(CVE-2025-21518)Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Security: Privileges).  Supported versions that are affected are 8.0.40 and prior, 8.4.3 and prior and  9.1.0 and prior. Difficult to exploit vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.4 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H).(CVE-2025-21519)Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Options).  Supported versions that are affected are 8.0.40 and prior, 8.4.3 and prior and  9.1.0 and prior. Difficult to exploit vulnerability allows high privileged attacker with logon to the infrastructure where MySQL Server executes to compromise MySQL Server.  Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in  unauthorized read access to a subset of MySQL Server accessible data. CVSS 3.1 Base Score 1.8 (Confidentiality impacts).  CVSS Vector: (CVSS:3.1/AV:L/AC:H/PR:H/UI:R/S:U/C:L/I:N/A:N).(CVE-2025-21520)Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Parser).  Supported versions that are affected are 8.0.40 and prior, 8.4.3 and prior and  9.1.0 and prior. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).(CVE-2025-21522)Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.40 and prior, 8.4.3 and prior and  9.1.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).(CVE-2025-21523)Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Information Schema).  Supported versions that are affected are 8.0.40 and prior, 8.4.3 and prior and  9.1.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).(CVE-2025-21529)Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.40 and prior, 8.4.3 and prior and  9.1.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).(CVE-2025-21531)Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Security: Privileges).  Supported versions that are affected are 8.0.40 and prior, 8.4.3 and prior and  9.1.0 and prior. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of MySQL Server accessible data as well as  unauthorized read access to a subset of MySQL Server accessible data. CVSS 3.1 Base Score 5.4 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N).(CVE-2025-21540)Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Packaging).  Supported versions that are affected are 8.0.40 and prior, 8.4.3 and prior and  9.1.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).(CVE-2025-21543)Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Security: Privileges).  Supported versions that are affected are 8.0.40 and prior, 8.4.3 and prior and  9.1.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of MySQL Server accessible data as well as  unauthorized read access to a subset of MySQL Server accessible data. CVSS 3.1 Base Score 3.8 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:N).(CVE-2025-21546)Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.40 and prior, 8.4.3 and prior and  9.1.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server as well as  unauthorized update, insert or delete access to some of MySQL Server accessible data. CVSS 3.1 Base Score 5.5 (Integrity and Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:H).(CVE-2025-21555)Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.40 and prior, 8.4.3 and prior and  9.1.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server as well as  unauthorized update, insert or delete access to some of MySQL Server accessible data. CVSS 3.1 Base Score 5.5 (Integrity and Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:H).(CVE-2025-21559)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="mysql" release="1.oe2203sp4" version="8.0.41">
                         <filename>mysql-8.0.41-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-common" release="1.oe2203sp4" version="8.0.41">
                         <filename>mysql-common-8.0.41-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-config" release="1.oe2203sp4" version="8.0.41">
                         <filename>mysql-config-8.0.41-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-debuginfo" release="1.oe2203sp4" version="8.0.41">
                         <filename>mysql-debuginfo-8.0.41-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-debugsource" release="1.oe2203sp4" version="8.0.41">
                         <filename>mysql-debugsource-8.0.41-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-devel" release="1.oe2203sp4" version="8.0.41">
                         <filename>mysql-devel-8.0.41-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-errmsg" release="1.oe2203sp4" version="8.0.41">
                         <filename>mysql-errmsg-8.0.41-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-help" release="1.oe2203sp4" version="8.0.41">
                         <filename>mysql-help-8.0.41-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-libs" release="1.oe2203sp4" version="8.0.41">
                         <filename>mysql-libs-8.0.41-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-server" release="1.oe2203sp4" version="8.0.41">
                         <filename>mysql-server-8.0.41-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-test" release="1.oe2203sp4" version="8.0.41">
                         <filename>mysql-test-8.0.41-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql" release="1.oe2203sp4" version="8.0.41">
                         <filename>mysql-8.0.41-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-common" release="1.oe2203sp4" version="8.0.41">
                         <filename>mysql-common-8.0.41-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-config" release="1.oe2203sp4" version="8.0.41">
                         <filename>mysql-config-8.0.41-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-debuginfo" release="1.oe2203sp4" version="8.0.41">
                         <filename>mysql-debuginfo-8.0.41-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-debugsource" release="1.oe2203sp4" version="8.0.41">
                         <filename>mysql-debugsource-8.0.41-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-devel" release="1.oe2203sp4" version="8.0.41">
                         <filename>mysql-devel-8.0.41-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-errmsg" release="1.oe2203sp4" version="8.0.41">
                         <filename>mysql-errmsg-8.0.41-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-help" release="1.oe2203sp4" version="8.0.41">
                         <filename>mysql-help-8.0.41-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-libs" release="1.oe2203sp4" version="8.0.41">
                         <filename>mysql-libs-8.0.41-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-server" release="1.oe2203sp4" version="8.0.41">
                         <filename>mysql-server-8.0.41-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-test" release="1.oe2203sp4" version="8.0.41">
                         <filename>mysql-test-8.0.41-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1107</id>
          <title>An update for libtasn1 is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2025-02-14"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-12133" id="CVE-2024-12133" title="CVE-2024-12133" type="cve"></reference>
          </references>
          <description>A flaw in libtasn1 causes inefficient handling of specific certificate data. When processing a large number of elements in a certificate, libtasn1 takes much longer than expected, which can slow down or even crash the system. This flaw allows an attacker to send a specially crafted certificate, causing a denial of service attack.(CVE-2024-12133)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libtasn1" release="2.oe2203sp4" version="4.19.0">
                         <filename>libtasn1-4.19.0-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtasn1-debuginfo" release="2.oe2203sp4" version="4.19.0">
                         <filename>libtasn1-debuginfo-4.19.0-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtasn1-debugsource" release="2.oe2203sp4" version="4.19.0">
                         <filename>libtasn1-debugsource-4.19.0-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtasn1-devel" release="2.oe2203sp4" version="4.19.0">
                         <filename>libtasn1-devel-4.19.0-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="libtasn1-help" release="2.oe2203sp4" version="4.19.0">
                         <filename>libtasn1-help-4.19.0-2.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtasn1" release="2.oe2203sp4" version="4.19.0">
                         <filename>libtasn1-4.19.0-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtasn1-debuginfo" release="2.oe2203sp4" version="4.19.0">
                         <filename>libtasn1-debuginfo-4.19.0-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtasn1-debugsource" release="2.oe2203sp4" version="4.19.0">
                         <filename>libtasn1-debugsource-4.19.0-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtasn1-devel" release="2.oe2203sp4" version="4.19.0">
                         <filename>libtasn1-devel-4.19.0-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1114</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-02-14"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47141" id="CVE-2024-47141" title="CVE-2024-47141" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49571" id="CVE-2024-49571" title="CVE-2024-49571" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50051" id="CVE-2024-50051" title="CVE-2024-50051" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53203" id="CVE-2024-53203" title="CVE-2024-53203" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53222" id="CVE-2024-53222" title="CVE-2024-53222" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53690" id="CVE-2024-53690" title="CVE-2024-53690" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57887" id="CVE-2024-57887" title="CVE-2024-57887" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57893" id="CVE-2024-57893" title="CVE-2024-57893" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57910" id="CVE-2024-57910" title="CVE-2024-57910" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:pinmux: Use sequential access to access desc-&gt;pinmux dataWhen two client of the same gpio call pinctrl_select_state() for thesame functionality, we are seeing NULL pointer issue while accessingdesc-&gt;mux_owner.Let&#39;s say two processes A, B executing in pin_request() for the same pinand process A updates the desc-&gt;mux_usecount but not yet updated thedesc-&gt;mux_owner while process B see the desc-&gt;mux_usecount which gotupdated by A path and further executes strcmp and while accessingdesc-&gt;mux_owner it crashes with NULL pointer.Serialize the access to mux related setting with a mutex lock.&#x9;cpu0 (process A)&#x9;&#x9;&#x9;cpu1(process B)pinctrl_select_state() {&#x9;&#x9;  pinctrl_select_state() {  pin_request() {&#x9;&#x9;&#x9;&#x9;pin_request() {  ...&#x9;&#x9;&#x9;&#x9;&#x9;&#x9; ....    } else {         desc-&gt;mux_usecount++;    &#x9;&#x9;&#x9;&#x9;&#x9;&#x9;desc-&gt;mux_usecount &amp;&amp; strcmp(desc-&gt;mux_owner, owner)) {         if (desc-&gt;mux_usecount &gt; 1)               return 0;         desc-&gt;mux_owner = owner;  }&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;}(CVE-2024-47141)In the Linux kernel, the following vulnerability has been resolved:net/smc: check iparea_offset and ipv6_prefixes_cnt when receiving proposal msgWhen receiving proposal msg in server, the field iparea_offsetand the field ipv6_prefixes_cnt in proposal msg are from theremote client and can not be fully trusted. Especially thefield iparea_offset, once exceed the max value, there has thechance to access wrong address, and crash may happen.This patch checks iparea_offset and ipv6_prefixes_cnt before using them.(CVE-2024-49571)In the Linux kernel, the following vulnerability has been resolved:spi: mpc52xx: Add cancel_work_sync before module removeIf we remove the module which will call mpc52xx_spi_removeit will free &#39;ms&#39; through spi_unregister_controller.while the work ms-&gt;work will be used. The sequence of operationsthat may lead to a UAF bug.Fix it by ensuring that the work is canceled before proceeding withthe cleanup in mpc52xx_spi_remove.(CVE-2024-50051)In the Linux kernel, the following vulnerability has been resolved:usb: typec: fix potential array underflow in ucsi_ccg_sync_control()The &#34;command&#34; variable can be controlled by the user via debugfs.  Theworry is that if con_index is zero then &#34;&amp;uc-&gt;ucsi-&gt;connector[con_index- 1]&#34; would be an array underflow.(CVE-2024-53203)In the Linux kernel, the following vulnerability has been resolved:zram: fix NULL pointer in comp_algorithm_show()LTP reported a NULL pointer dereference as followed: CPU: 7 UID: 0 PID: 5995 Comm: cat Kdump: loaded Not tainted 6.12.0-rc6+ #3 Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __pi_strcmp+0x24/0x140 lr : zcomp_available_show+0x60/0x100 [zram] sp : ffff800088b93b90 x29: ffff800088b93b90 x28: 0000000000000001 x27: 0000000000400cc0 x26: 0000000000000ffe x25: ffff80007b3e2388 x24: 0000000000000000 x23: ffff80007b3e2390 x22: ffff0004041a9000 x21: ffff80007b3e2900 x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: ffff80007b3e2900 x9 : ffff80007b3cb280 x8 : 0101010101010101 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000040 x4 : 0000000000000000 x3 : 00656c722d6f7a6c x2 : 0000000000000000 x1 : ffff80007b3e2900 x0 : 0000000000000000 Call trace:  __pi_strcmp+0x24/0x140  comp_algorithm_show+0x40/0x70 [zram]  dev_attr_show+0x28/0x80  sysfs_kf_seq_show+0x90/0x140  kernfs_seq_show+0x34/0x48  seq_read_iter+0x1d4/0x4e8  kernfs_fop_read_iter+0x40/0x58  new_sync_read+0x9c/0x168  vfs_read+0x1a8/0x1f8  ksys_read+0x74/0x108  __arm64_sys_read+0x24/0x38  invoke_syscall+0x50/0x120  el0_svc_common.constprop.0+0xc8/0xf0  do_el0_svc+0x24/0x38  el0_svc+0x38/0x138  el0t_64_sync_handler+0xc0/0xc8  el0t_64_sync+0x188/0x190The zram-&gt;comp_algs[ZRAM_PRIMARY_COMP] can be NULL in zram_add() ifcomp_algorithm_set() has not been called.  User can access the zram deviceby sysfs after device_add_disk(), so there is a time window to trigger theNULL pointer dereference.  Move it ahead device_add_disk() to make surewhen user can access the zram device, it is ready.  comp_algorithm_set()is protected by zram-&gt;init_lock in other places and no such problem.(CVE-2024-53222)In the Linux kernel, the following vulnerability has been resolved:nilfs2: prevent use of deleted inodesyzbot reported a WARNING in nilfs_rmdir. [1]Because the inode bitmap is corrupted, an inode with an inode number thatshould exist as a &#34;.nilfs&#34; file was reassigned by nilfs_mkdir for &#34;file0&#34;,causing an inode duplication during execution.  And this causes anunderflow of i_nlink in rmdir operations.The inode is used twice by the same task to unmount and remove directories&#34;.nilfs&#34; and &#34;file0&#34;, it trigger warning in nilfs_rmdir.Avoid to this issue, check i_nlink in nilfs_iget(), if it is 0, it meansthat this inode has been deleted, and iput is executed to reclaim it.[1]WARNING: CPU: 1 PID: 5824 at fs/inode.c:407 drop_nlink+0xc4/0x110 fs/inode.c:407...Call Trace: &lt;TASK&gt; nilfs_rmdir+0x1b0/0x250 fs/nilfs2/namei.c:342 vfs_rmdir+0x3a3/0x510 fs/namei.c:4394 do_rmdir+0x3b5/0x580 fs/namei.c:4453 __do_sys_rmdir fs/namei.c:4472 [inline] __se_sys_rmdir fs/namei.c:4470 [inline] __x64_sys_rmdir+0x47/0x50 fs/namei.c:4470 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-53690)In the Linux kernel, the following vulnerability has been resolved:drm: adv7511: Fix use-after-free in adv7533_attach_dsi()The host_node pointer was assigned and freed in adv7533_parse_dt(), andlater, adv7533_attach_dsi() uses the same. Fix this use-after-free issueby dropping of_node_put() in adv7533_parse_dt() and calling of_node_put()in error path of probe() and also in the remove().(CVE-2024-57887)In the Linux kernel, the following vulnerability has been resolved:ALSA: seq: oss: Fix races at processing SysEx messagesOSS sequencer handles the SysEx messages split in 6 bytes packets, andALSA sequencer OSS layer tries to combine those.  It stores the datain the internal buffer and this access is racy as of now, which maylead to the out-of-bounds access.As a temporary band-aid fix, introduce a mutex for serializing theprocess of the SysEx message packets.(CVE-2024-57893)In the Linux kernel, the following vulnerability has been resolved:iio: light: vcnl4035: fix information leak in triggered bufferThe &#39;buffer&#39; local array is used to push data to userspace from atriggered buffer, but it does not set an initial value for the singledata element, which is an u16 aligned to 8 bytes. That leaves at least4 bytes uninitialized even after writing an integer value withregmap_read().Initialize the array to zero before using it to avoid pushinguninitialized information to userspace.(CVE-2024-57910)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="bpftool" release="249.0.0.152.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-249.0.0.152.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="249.0.0.152.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-249.0.0.152.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="249.0.0.152.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-249.0.0.152.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="249.0.0.152.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-249.0.0.152.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="249.0.0.152.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-249.0.0.152.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="249.0.0.152.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-249.0.0.152.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="249.0.0.152.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-249.0.0.152.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="249.0.0.152.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-249.0.0.152.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="249.0.0.152.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-249.0.0.152.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="249.0.0.152.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-249.0.0.152.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="249.0.0.152.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-249.0.0.152.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="249.0.0.152.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-249.0.0.152.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="249.0.0.152.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-249.0.0.152.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="249.0.0.152.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-249.0.0.152.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="249.0.0.152.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-249.0.0.152.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="249.0.0.152.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-249.0.0.152.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="249.0.0.152.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-249.0.0.152.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="249.0.0.152.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-249.0.0.152.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="249.0.0.152.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-249.0.0.152.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="249.0.0.152.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-249.0.0.152.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="249.0.0.152.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-249.0.0.152.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="249.0.0.152.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-249.0.0.152.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="249.0.0.152.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-249.0.0.152.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="249.0.0.152.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-249.0.0.152.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="249.0.0.152.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-249.0.0.152.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="249.0.0.152.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-249.0.0.152.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="249.0.0.152.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-249.0.0.152.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="249.0.0.152.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-249.0.0.152.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="249.0.0.152.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-249.0.0.152.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="249.0.0.152.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-249.0.0.152.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1115</id>
          <title>An update for git is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-02-14"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-52005" id="CVE-2024-52005" title="CVE-2024-52005" type="cve"></reference>
          </references>
          <description>Git is a source code management tool. When cloning from a server (or fetching, or pushing), informational or error messages are transported from the remote Git process to the client via the so-called &#34;sideband channel&#34;. These messages will be prefixed with &#34;remote:&#34; and printed directly to the standard error output. Typically, this standard error output is connected to a terminal that understands ANSI escape sequences, which Git did not protect against. Most modern terminals support control sequences that can be used by a malicious actor to hide and misrepresent information, or to mislead the user into executing untrusted scripts. As requested on the git-security mailing list, the patches are under discussion on the public mailing list. Users are advised to update as soon as possible. Users unable to upgrade should avoid recursive clones unless they are from trusted sources.(CVE-2024-52005)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="git" release="17.oe2203sp4" version="2.33.0">
                         <filename>git-2.33.0-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="git-core" release="17.oe2203sp4" version="2.33.0">
                         <filename>git-core-2.33.0-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="git-daemon" release="17.oe2203sp4" version="2.33.0">
                         <filename>git-daemon-2.33.0-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="git-debuginfo" release="17.oe2203sp4" version="2.33.0">
                         <filename>git-debuginfo-2.33.0-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="git-debugsource" release="17.oe2203sp4" version="2.33.0">
                         <filename>git-debugsource-2.33.0-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="git-email" release="17.oe2203sp4" version="2.33.0">
                         <filename>git-email-2.33.0-17.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="git-gui" release="17.oe2203sp4" version="2.33.0">
                         <filename>git-gui-2.33.0-17.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="git-help" release="17.oe2203sp4" version="2.33.0">
                         <filename>git-help-2.33.0-17.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="git-svn" release="17.oe2203sp4" version="2.33.0">
                         <filename>git-svn-2.33.0-17.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="git-web" release="17.oe2203sp4" version="2.33.0">
                         <filename>git-web-2.33.0-17.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="gitk" release="17.oe2203sp4" version="2.33.0">
                         <filename>gitk-2.33.0-17.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="perl-Git" release="17.oe2203sp4" version="2.33.0">
                         <filename>perl-Git-2.33.0-17.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="perl-Git-SVN" release="17.oe2203sp4" version="2.33.0">
                         <filename>perl-Git-SVN-2.33.0-17.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="git" release="17.oe2203sp4" version="2.33.0">
                         <filename>git-2.33.0-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="git-core" release="17.oe2203sp4" version="2.33.0">
                         <filename>git-core-2.33.0-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="git-daemon" release="17.oe2203sp4" version="2.33.0">
                         <filename>git-daemon-2.33.0-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="git-debuginfo" release="17.oe2203sp4" version="2.33.0">
                         <filename>git-debuginfo-2.33.0-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="git-debugsource" release="17.oe2203sp4" version="2.33.0">
                         <filename>git-debugsource-2.33.0-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1117</id>
          <title>An update for cpp-httplib is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-02-14"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-0825" id="CVE-2025-0825" title="CVE-2025-0825" type="cve"></reference>
          </references>
          <description>cpp-httplib version v0.17.3 through v0.18.3 fails to filter CRLF characters (&#34;\r\n&#34;) when those are prefixed with a null byte. This enables attackers to exploit CRLF injection that could further lead to HTTP Response Splitting, XSS, and more.(CVE-2025-0825)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="cpp-httplib" release="3.oe2203sp4" version="0.12.4">
                         <filename>cpp-httplib-0.12.4-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cpp-httplib" release="3.oe2203sp4" version="0.12.4">
                         <filename>cpp-httplib-0.12.4-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1123</id>
          <title>An update for etcd is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-02-14"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-24675" id="CVE-2022-24675" title="CVE-2022-24675" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-24921" id="CVE-2022-24921" title="CVE-2022-24921" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-28327" id="CVE-2022-28327" title="CVE-2022-28327" type="cve"></reference>
          </references>
          <description>encoding/pem in Go before 1.17.9 and 1.18.x before 1.18.1 has a Decode stack overflow via a large amount of PEM data.(CVE-2022-24675)regexp.Compile in Go before 1.16.15 and 1.17.x before 1.17.8 allows stack exhaustion via a deeply nested expression.(CVE-2022-24921)The generic P-256 feature in crypto/elliptic in Go before 1.17.9 and 1.18.x before 1.18.1 allows a panic via long scalar input.(CVE-2022-28327)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="etcd" release="7.oe2203sp4" version="3.4.14">
                         <filename>etcd-3.4.14-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="etcd" release="7.oe2203sp4" version="3.4.14">
                         <filename>etcd-3.4.14-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1125</id>
          <title>An update for ansible is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-02-14"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3697" id="CVE-2022-3697" title="CVE-2022-3697" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5115" id="CVE-2023-5115" title="CVE-2023-5115" type="cve"></reference>
          </references>
          <description>A flaw was found in Ansible in the amazon.aws collection when using the tower_callback parameter from the amazon.aws.ec2_instance module. This flaw allows an attacker to take advantage of this issue as the module is handling the parameter insecurely, leading to the password leaking in the logs.(CVE-2022-3697)An absolute path traversal attack exists in the Ansible automation platform. This flaw allows an attacker to craft a malicious Ansible role and make the victim execute the role. A symlink can be used to overwrite a file outside of the extraction path.(CVE-2023-5115)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="ansible" release="6.oe2203sp4" version="2.9.27">
                         <filename>ansible-2.9.27-6.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="ansible-help" release="6.oe2203sp4" version="2.9.27">
                         <filename>ansible-help-2.9.27-6.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1132</id>
          <title>An update for ark is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-02-14"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57966" id="CVE-2024-57966" title="CVE-2024-57966" type="cve"></reference>
          </references>
          <description>libarchiveplugin.cpp in KDE ark before 24.12.0 can extract to an absolute path from an archive.(CVE-2024-57966)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="ark" release="2.oe2203sp4" version="22.08.3">
                         <filename>ark-22.08.3-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ark-debuginfo" release="2.oe2203sp4" version="22.08.3">
                         <filename>ark-debuginfo-22.08.3-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ark-debugsource" release="2.oe2203sp4" version="22.08.3">
                         <filename>ark-debugsource-22.08.3-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ark-libs" release="2.oe2203sp4" version="22.08.3">
                         <filename>ark-libs-22.08.3-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ark" release="2.oe2203sp4" version="22.08.3">
                         <filename>ark-22.08.3-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ark-debuginfo" release="2.oe2203sp4" version="22.08.3">
                         <filename>ark-debuginfo-22.08.3-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ark-debugsource" release="2.oe2203sp4" version="22.08.3">
                         <filename>ark-debugsource-22.08.3-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ark-libs" release="2.oe2203sp4" version="22.08.3">
                         <filename>ark-libs-22.08.3-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1134</id>
          <title>An update for nginx is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-02-14"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-23419" id="CVE-2025-23419" title="CVE-2025-23419" type="cve"></reference>
          </references>
          <description>When multiple server blocks are configured to share the same IP address and port, an attacker can use session resumption to bypass client certificate authentication requirements on these servers. This vulnerability arises when  TLS Session Tickets https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_ticket_key  are used and/or the  SSL session cache https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_cache  are used in the default server and the default server is performing client certificate authentication.  Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.(CVE-2025-23419)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="nginx" release="8.oe2203sp4" version="1.21.5">
                         <filename>nginx-1.21.5-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nginx-debuginfo" release="8.oe2203sp4" version="1.21.5">
                         <filename>nginx-debuginfo-1.21.5-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nginx-debugsource" release="8.oe2203sp4" version="1.21.5">
                         <filename>nginx-debugsource-1.21.5-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nginx-mod-devel" release="8.oe2203sp4" version="1.21.5">
                         <filename>nginx-mod-devel-1.21.5-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nginx-mod-http-image-filter" release="8.oe2203sp4" version="1.21.5">
                         <filename>nginx-mod-http-image-filter-1.21.5-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nginx-mod-http-perl" release="8.oe2203sp4" version="1.21.5">
                         <filename>nginx-mod-http-perl-1.21.5-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nginx-mod-http-xslt-filter" release="8.oe2203sp4" version="1.21.5">
                         <filename>nginx-mod-http-xslt-filter-1.21.5-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nginx-mod-mail" release="8.oe2203sp4" version="1.21.5">
                         <filename>nginx-mod-mail-1.21.5-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nginx-mod-stream" release="8.oe2203sp4" version="1.21.5">
                         <filename>nginx-mod-stream-1.21.5-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="nginx-all-modules" release="8.oe2203sp4" version="1.21.5">
                         <filename>nginx-all-modules-1.21.5-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="nginx-filesystem" release="8.oe2203sp4" version="1.21.5">
                         <filename>nginx-filesystem-1.21.5-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="nginx-help" release="8.oe2203sp4" version="1.21.5">
                         <filename>nginx-help-1.21.5-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nginx" release="8.oe2203sp4" version="1.21.5">
                         <filename>nginx-1.21.5-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nginx-debuginfo" release="8.oe2203sp4" version="1.21.5">
                         <filename>nginx-debuginfo-1.21.5-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nginx-debugsource" release="8.oe2203sp4" version="1.21.5">
                         <filename>nginx-debugsource-1.21.5-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nginx-mod-devel" release="8.oe2203sp4" version="1.21.5">
                         <filename>nginx-mod-devel-1.21.5-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nginx-mod-http-image-filter" release="8.oe2203sp4" version="1.21.5">
                         <filename>nginx-mod-http-image-filter-1.21.5-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nginx-mod-http-perl" release="8.oe2203sp4" version="1.21.5">
                         <filename>nginx-mod-http-perl-1.21.5-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nginx-mod-http-xslt-filter" release="8.oe2203sp4" version="1.21.5">
                         <filename>nginx-mod-http-xslt-filter-1.21.5-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nginx-mod-mail" release="8.oe2203sp4" version="1.21.5">
                         <filename>nginx-mod-mail-1.21.5-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nginx-mod-stream" release="8.oe2203sp4" version="1.21.5">
                         <filename>nginx-mod-stream-1.21.5-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1135</id>
          <title>An update for krb5 is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-02-14"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-24528" id="CVE-2025-24528" title="CVE-2025-24528" type="cve"></reference>
          </references>
          <description>In MIT krb5 release 1.7 and later with incremental propagationenabled, an authenticated attacker can cause kadmind to write beyondthe end of the mapped region for the iprop log file, likely causing aprocess crash.(CVE-2025-24528)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="krb5" release="23.oe2203sp4" version="1.19.2">
                         <filename>krb5-1.19.2-23.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="krb5-client" release="23.oe2203sp4" version="1.19.2">
                         <filename>krb5-client-1.19.2-23.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="krb5-debuginfo" release="23.oe2203sp4" version="1.19.2">
                         <filename>krb5-debuginfo-1.19.2-23.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="krb5-debugsource" release="23.oe2203sp4" version="1.19.2">
                         <filename>krb5-debugsource-1.19.2-23.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="krb5-devel" release="23.oe2203sp4" version="1.19.2">
                         <filename>krb5-devel-1.19.2-23.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="krb5-libs" release="23.oe2203sp4" version="1.19.2">
                         <filename>krb5-libs-1.19.2-23.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="krb5-server" release="23.oe2203sp4" version="1.19.2">
                         <filename>krb5-server-1.19.2-23.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="krb5-help" release="23.oe2203sp4" version="1.19.2">
                         <filename>krb5-help-1.19.2-23.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="krb5" release="23.oe2203sp4" version="1.19.2">
                         <filename>krb5-1.19.2-23.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="krb5-client" release="23.oe2203sp4" version="1.19.2">
                         <filename>krb5-client-1.19.2-23.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="krb5-debuginfo" release="23.oe2203sp4" version="1.19.2">
                         <filename>krb5-debuginfo-1.19.2-23.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="krb5-debugsource" release="23.oe2203sp4" version="1.19.2">
                         <filename>krb5-debugsource-1.19.2-23.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="krb5-devel" release="23.oe2203sp4" version="1.19.2">
                         <filename>krb5-devel-1.19.2-23.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="krb5-libs" release="23.oe2203sp4" version="1.19.2">
                         <filename>krb5-libs-1.19.2-23.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="krb5-server" release="23.oe2203sp4" version="1.19.2">
                         <filename>krb5-server-1.19.2-23.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1136</id>
          <title>An update for vim is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-02-14"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-24014" id="CVE-2025-24014" title="CVE-2025-24014" type="cve"></reference>
          </references>
          <description>Vim is an open source, command line text editor. A segmentation fault was found in Vim before 9.1.1043. In silent Ex mode (-s -e), Vim typically doesn&#39;t show a screen and just operates silently in batch mode. However, it is still possible to trigger the function that handles the scrolling of a gui version of Vim by feeding some binary characters to Vim. The function that handles the scrolling however may be triggering a redraw, which will access the ScreenLines pointer, even so this variable hasn&#39;t been allocated (since there is no screen). This vulnerability is fixed in 9.1.1043.(CVE-2025-24014)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="2" arch="aarch64" name="vim-X11" release="31.oe2203sp4" version="9.0">
                         <filename>vim-X11-9.0-31.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-common" release="31.oe2203sp4" version="9.0">
                         <filename>vim-common-9.0-31.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-debuginfo" release="31.oe2203sp4" version="9.0">
                         <filename>vim-debuginfo-9.0-31.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-debugsource" release="31.oe2203sp4" version="9.0">
                         <filename>vim-debugsource-9.0-31.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-enhanced" release="31.oe2203sp4" version="9.0">
                         <filename>vim-enhanced-9.0-31.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-minimal" release="31.oe2203sp4" version="9.0">
                         <filename>vim-minimal-9.0-31.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="noarch" name="vim-filesystem" release="31.oe2203sp4" version="9.0">
                         <filename>vim-filesystem-9.0-31.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-X11" release="31.oe2203sp4" version="9.0">
                         <filename>vim-X11-9.0-31.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-common" release="31.oe2203sp4" version="9.0">
                         <filename>vim-common-9.0-31.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-debuginfo" release="31.oe2203sp4" version="9.0">
                         <filename>vim-debuginfo-9.0-31.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-debugsource" release="31.oe2203sp4" version="9.0">
                         <filename>vim-debugsource-9.0-31.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-enhanced" release="31.oe2203sp4" version="9.0">
                         <filename>vim-enhanced-9.0-31.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-minimal" release="31.oe2203sp4" version="9.0">
                         <filename>vim-minimal-9.0-31.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1137</id>
          <title>An update for jss is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-02-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4132" id="CVE-2022-4132" title="CVE-2022-4132" type="cve"></reference>
          </references>
          <description>A flaw was found in JSS. A memory leak in JSS requires non-standard configuration but is a low-effort DoS vector if configured that way (repeatedly hitting the login page).(CVE-2022-4132)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="jss" release="3.oe2203sp4" version="5.1.0">
                         <filename>jss-5.1.0-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="jss-debuginfo" release="3.oe2203sp4" version="5.1.0">
                         <filename>jss-debuginfo-5.1.0-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="jss-debugsource" release="3.oe2203sp4" version="5.1.0">
                         <filename>jss-debugsource-5.1.0-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="jss-help" release="3.oe2203sp4" version="5.1.0">
                         <filename>jss-help-5.1.0-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="jss" release="3.oe2203sp4" version="5.1.0">
                         <filename>jss-5.1.0-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="jss-debuginfo" release="3.oe2203sp4" version="5.1.0">
                         <filename>jss-debuginfo-5.1.0-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="jss-debugsource" release="3.oe2203sp4" version="5.1.0">
                         <filename>jss-debugsource-5.1.0-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="jss-help" release="3.oe2203sp4" version="5.1.0">
                         <filename>jss-help-5.1.0-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1139</id>
          <title>An update for python-dns is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2025-02-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29483" id="CVE-2023-29483" title="CVE-2023-29483" type="cve"></reference>
          </references>
          <description>eventlet before 0.35.2, as used in dnspython before 2.6.0, allows remote attackers to interfere with DNS name resolution by quickly sending an invalid packet from the expected IP address and source port, aka a &#34;TuDoor&#34; attack. In other words, dnspython does not have the preferred behavior in which the DNS name resolution algorithm would proceed, within the full time window, in order to wait for a valid packet. NOTE: dnspython 2.6.0 is unusable for a different reason that was addressed in 2.6.1.(CVE-2023-29483)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="python-dns-help" release="3.oe2203sp4" version="2.2.1">
                         <filename>python-dns-help-2.2.1-3.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-dns" release="3.oe2203sp4" version="2.2.1">
                         <filename>python3-dns-2.2.1-3.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1147</id>
          <title>An update for three-eight-nine-ds-base is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-02-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-8445" id="CVE-2024-8445" title="CVE-2024-8445" type="cve"></reference>
          </references>
          <description>The fix for CVE-2024-2199 in 389-ds-base was insufficient to cover all scenarios. In certain product versions, an authenticated user may cause a server crash while modifying `userPassword` using malformed input.(CVE-2024-8445)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="389-ds-base" release="9.oe2203sp4" version="1.4.3.36">
                         <filename>389-ds-base-1.4.3.36-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="389-ds-base-debuginfo" release="9.oe2203sp4" version="1.4.3.36">
                         <filename>389-ds-base-debuginfo-1.4.3.36-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="389-ds-base-debugsource" release="9.oe2203sp4" version="1.4.3.36">
                         <filename>389-ds-base-debugsource-1.4.3.36-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="389-ds-base-devel" release="9.oe2203sp4" version="1.4.3.36">
                         <filename>389-ds-base-devel-1.4.3.36-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="389-ds-base-help" release="9.oe2203sp4" version="1.4.3.36">
                         <filename>389-ds-base-help-1.4.3.36-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="389-ds-base-legacy-tools" release="9.oe2203sp4" version="1.4.3.36">
                         <filename>389-ds-base-legacy-tools-1.4.3.36-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="389-ds-base-snmp" release="9.oe2203sp4" version="1.4.3.36">
                         <filename>389-ds-base-snmp-1.4.3.36-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="cockpit-389-ds" release="9.oe2203sp4" version="1.4.3.36">
                         <filename>cockpit-389-ds-1.4.3.36-9.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-lib389" release="9.oe2203sp4" version="1.4.3.36">
                         <filename>python3-lib389-1.4.3.36-9.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="389-ds-base" release="9.oe2203sp4" version="1.4.3.36">
                         <filename>389-ds-base-1.4.3.36-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="389-ds-base-debuginfo" release="9.oe2203sp4" version="1.4.3.36">
                         <filename>389-ds-base-debuginfo-1.4.3.36-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="389-ds-base-debugsource" release="9.oe2203sp4" version="1.4.3.36">
                         <filename>389-ds-base-debugsource-1.4.3.36-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="389-ds-base-devel" release="9.oe2203sp4" version="1.4.3.36">
                         <filename>389-ds-base-devel-1.4.3.36-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="389-ds-base-help" release="9.oe2203sp4" version="1.4.3.36">
                         <filename>389-ds-base-help-1.4.3.36-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="389-ds-base-legacy-tools" release="9.oe2203sp4" version="1.4.3.36">
                         <filename>389-ds-base-legacy-tools-1.4.3.36-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="389-ds-base-snmp" release="9.oe2203sp4" version="1.4.3.36">
                         <filename>389-ds-base-snmp-1.4.3.36-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1149</id>
          <title>An update for python3 is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-02-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-0938" id="CVE-2025-0938" title="CVE-2025-0938" type="cve"></reference>
          </references>
          <description>The Python standard library functions `urllib.parse.urlsplit` and `urlparse` accepted domain names that included square brackets which isn&#39;t valid according to RFC 3986. Square brackets are only meant to be used as delimiters for specifying IPv6 and IPvFuture hosts in URLs. This could result in differential parsing across the Python URL parser and other specification-compliant URL parsers.(CVE-2025-0938)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="python3" release="41.oe2203sp4" version="3.9.9">
                         <filename>python3-3.9.9-41.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-debug" release="41.oe2203sp4" version="3.9.9">
                         <filename>python3-debug-3.9.9-41.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-debuginfo" release="41.oe2203sp4" version="3.9.9">
                         <filename>python3-debuginfo-3.9.9-41.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-debugsource" release="41.oe2203sp4" version="3.9.9">
                         <filename>python3-debugsource-3.9.9-41.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-devel" release="41.oe2203sp4" version="3.9.9">
                         <filename>python3-devel-3.9.9-41.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-unversioned-command" release="41.oe2203sp4" version="3.9.9">
                         <filename>python3-unversioned-command-3.9.9-41.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-help" release="41.oe2203sp4" version="3.9.9">
                         <filename>python3-help-3.9.9-41.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3" release="41.oe2203sp4" version="3.9.9">
                         <filename>python3-3.9.9-41.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-debug" release="41.oe2203sp4" version="3.9.9">
                         <filename>python3-debug-3.9.9-41.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-debuginfo" release="41.oe2203sp4" version="3.9.9">
                         <filename>python3-debuginfo-3.9.9-41.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-debugsource" release="41.oe2203sp4" version="3.9.9">
                         <filename>python3-debugsource-3.9.9-41.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-devel" release="41.oe2203sp4" version="3.9.9">
                         <filename>python3-devel-3.9.9-41.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-unversioned-command" release="41.oe2203sp4" version="3.9.9">
                         <filename>python3-unversioned-command-3.9.9-41.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1154</id>
          <title>An update for postgresql is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-02-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1094" id="CVE-2025-1094" title="CVE-2025-1094" type="cve"></reference>
          </references>
          <description>Improper neutralization of quoting syntax in PostgreSQL libpq functions PQescapeLiteral(), PQescapeIdentifier(), PQescapeString(), and PQescapeStringConn() allows a database input provider to achieve SQL injection in certain usage patterns.  Specifically, SQL injection requires the application to use the function result to construct input to psql, the PostgreSQL interactive terminal.  Similarly, improper neutralization of quoting syntax in PostgreSQL command line utility programs allows a source of command line arguments to achieve SQL injection when client_encoding is BIG5 and server_encoding is one of EUC_TW or MULE_INTERNAL.  Versions before PostgreSQL 17.3, 16.7, 15.11, 14.16, and 13.19 are affected.(CVE-2025-1094)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="postgresql" release="1.oe2203sp4" version="13.19">
                         <filename>postgresql-13.19-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-contrib" release="1.oe2203sp4" version="13.19">
                         <filename>postgresql-contrib-13.19-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-debuginfo" release="1.oe2203sp4" version="13.19">
                         <filename>postgresql-debuginfo-13.19-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-debugsource" release="1.oe2203sp4" version="13.19">
                         <filename>postgresql-debugsource-13.19-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-docs" release="1.oe2203sp4" version="13.19">
                         <filename>postgresql-docs-13.19-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-llvmjit" release="1.oe2203sp4" version="13.19">
                         <filename>postgresql-llvmjit-13.19-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-plperl" release="1.oe2203sp4" version="13.19">
                         <filename>postgresql-plperl-13.19-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-plpython3" release="1.oe2203sp4" version="13.19">
                         <filename>postgresql-plpython3-13.19-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-pltcl" release="1.oe2203sp4" version="13.19">
                         <filename>postgresql-pltcl-13.19-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-private-devel" release="1.oe2203sp4" version="13.19">
                         <filename>postgresql-private-devel-13.19-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-private-libs" release="1.oe2203sp4" version="13.19">
                         <filename>postgresql-private-libs-13.19-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-server" release="1.oe2203sp4" version="13.19">
                         <filename>postgresql-server-13.19-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-server-devel" release="1.oe2203sp4" version="13.19">
                         <filename>postgresql-server-devel-13.19-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-static" release="1.oe2203sp4" version="13.19">
                         <filename>postgresql-static-13.19-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-test" release="1.oe2203sp4" version="13.19">
                         <filename>postgresql-test-13.19-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="postgresql-test-rpm-macros" release="1.oe2203sp4" version="13.19">
                         <filename>postgresql-test-rpm-macros-13.19-1.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql" release="1.oe2203sp4" version="13.19">
                         <filename>postgresql-13.19-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-contrib" release="1.oe2203sp4" version="13.19">
                         <filename>postgresql-contrib-13.19-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-debuginfo" release="1.oe2203sp4" version="13.19">
                         <filename>postgresql-debuginfo-13.19-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-debugsource" release="1.oe2203sp4" version="13.19">
                         <filename>postgresql-debugsource-13.19-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-docs" release="1.oe2203sp4" version="13.19">
                         <filename>postgresql-docs-13.19-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-llvmjit" release="1.oe2203sp4" version="13.19">
                         <filename>postgresql-llvmjit-13.19-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-plperl" release="1.oe2203sp4" version="13.19">
                         <filename>postgresql-plperl-13.19-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-plpython3" release="1.oe2203sp4" version="13.19">
                         <filename>postgresql-plpython3-13.19-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-pltcl" release="1.oe2203sp4" version="13.19">
                         <filename>postgresql-pltcl-13.19-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-private-devel" release="1.oe2203sp4" version="13.19">
                         <filename>postgresql-private-devel-13.19-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-private-libs" release="1.oe2203sp4" version="13.19">
                         <filename>postgresql-private-libs-13.19-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-server" release="1.oe2203sp4" version="13.19">
                         <filename>postgresql-server-13.19-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-server-devel" release="1.oe2203sp4" version="13.19">
                         <filename>postgresql-server-devel-13.19-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-static" release="1.oe2203sp4" version="13.19">
                         <filename>postgresql-static-13.19-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-test" release="1.oe2203sp4" version="13.19">
                         <filename>postgresql-test-13.19-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1156</id>
          <title>An update for yajl is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-02-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2017-16516" id="CVE-2017-16516" title="CVE-2017-16516" type="cve"></reference>
          </references>
          <description>In the yajl-ruby gem 1.3.0 for Ruby, when a crafted JSON file is supplied to Yajl::Parser.new.parse, the whole ruby process crashes with a SIGABRT in the yajl_string_decode function in yajl_encode.c. This results in the whole ruby process terminating and potentially a denial of service.(CVE-2017-16516)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="yajl" release="21.oe2203sp4" version="2.1.0">
                         <filename>yajl-2.1.0-21.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="yajl-debuginfo" release="21.oe2203sp4" version="2.1.0">
                         <filename>yajl-debuginfo-2.1.0-21.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="yajl-debugsource" release="21.oe2203sp4" version="2.1.0">
                         <filename>yajl-debugsource-2.1.0-21.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="yajl-devel" release="21.oe2203sp4" version="2.1.0">
                         <filename>yajl-devel-2.1.0-21.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="yajl" release="21.oe2203sp4" version="2.1.0">
                         <filename>yajl-2.1.0-21.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="yajl-debuginfo" release="21.oe2203sp4" version="2.1.0">
                         <filename>yajl-debuginfo-2.1.0-21.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="yajl-debugsource" release="21.oe2203sp4" version="2.1.0">
                         <filename>yajl-debugsource-2.1.0-21.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="yajl-devel" release="21.oe2203sp4" version="2.1.0">
                         <filename>yajl-devel-2.1.0-21.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1157</id>
          <title>An update for redis is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-02-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-32626" id="CVE-2021-32626" title="CVE-2021-32626" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-32627" id="CVE-2021-32627" title="CVE-2021-32627" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-32628" id="CVE-2021-32628" title="CVE-2021-32628" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-32675" id="CVE-2021-32675" title="CVE-2021-32675" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-32687" id="CVE-2021-32687" title="CVE-2021-32687" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-32762" id="CVE-2021-32762" title="CVE-2021-32762" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-41099" id="CVE-2021-41099" title="CVE-2021-41099" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-24735" id="CVE-2022-24735" title="CVE-2022-24735" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-24736" id="CVE-2022-24736" title="CVE-2022-24736" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-35977" id="CVE-2022-35977" title="CVE-2022-35977" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3647" id="CVE-2022-3647" title="CVE-2022-3647" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25155" id="CVE-2023-25155" title="CVE-2023-25155" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46981" id="CVE-2024-46981" title="CVE-2024-46981" type="cve"></reference>
          </references>
          <description>Redis is an open source, in-memory database that persists on disk. In affected versions specially crafted Lua scripts executing in Redis can cause the heap-based Lua stack to be overflowed, due to incomplete checks for this condition. This can result with heap corruption and potentially remote code execution. This problem exists in all versions of Redis with Lua scripting support, starting from 2.6. The problem is fixed in versions 6.2.6, 6.0.16 and 5.0.14. For users unable to update an additional workaround to mitigate the problem without patching the redis-server executable is to prevent users from executing Lua scripts. This can be done using ACL to restrict EVAL and EVALSHA commands.(CVE-2021-32626)Redis is an open source, in-memory database that persists on disk. In affected versions an integer overflow bug in Redis can be exploited to corrupt the heap and potentially result with remote code execution. The vulnerability involves changing the default proto-max-bulk-len and client-query-buffer-limit configuration parameters to very large values and constructing specially crafted very large stream elements. The problem is fixed in Redis 6.2.6, 6.0.16 and 5.0.14. For users unable to upgrade an additional workaround to mitigate the problem without patching the redis-server executable is to prevent users from modifying the proto-max-bulk-len configuration parameter. This can be done using ACL to restrict unprivileged users from using the CONFIG SET command.(CVE-2021-32627)Redis is an open source, in-memory database that persists on disk. An integer overflow bug in the ziplist data structure used by all versions of Redis can be exploited to corrupt the heap and potentially result with remote code execution. The vulnerability involves modifying the default ziplist configuration parameters (hash-max-ziplist-entries, hash-max-ziplist-value, zset-max-ziplist-entries or zset-max-ziplist-value) to a very large value, and then constructing specially crafted commands to create very large ziplists. The problem is fixed in Redis versions 6.2.6, 6.0.16, 5.0.14. An additional workaround to mitigate the problem without patching the redis-server executable is to prevent users from modifying the above configuration parameters. This can be done using ACL to restrict unprivileged users from using the CONFIG SET command.(CVE-2021-32628)Redis is an open source, in-memory database that persists on disk. When parsing an incoming Redis Standard Protocol (RESP) request, Redis allocates memory according to user-specified values which determine the number of elements (in the multi-bulk header) and size of each element (in the bulk header). An attacker delivering specially crafted requests over multiple connections can cause the server to allocate significant amount of memory. Because the same parsing mechanism is used to handle authentication requests, this vulnerability can also be exploited by unauthenticated users. The problem is fixed in Redis versions 6.2.6, 6.0.16 and 5.0.14. An additional workaround to mitigate this problem without patching the redis-server executable is to block access to prevent unauthenticated users from connecting to Redis. This can be done in different ways: Using network access control tools like firewalls, iptables, security groups, etc. or Enabling TLS and requiring users to authenticate using client side certificates.(CVE-2021-32675)Redis is an open source, in-memory database that persists on disk. An integer overflow bug affecting all versions of Redis can be exploited to corrupt the heap and potentially be used to leak arbitrary contents of the heap or trigger remote code execution. The vulnerability involves changing the default set-max-intset-entries configuration parameter to a very large value and constructing specially crafted commands to manipulate sets. The problem is fixed in Redis versions 6.2.6, 6.0.16 and 5.0.14. An additional workaround to mitigate the problem without patching the redis-server executable is to prevent users from modifying the set-max-intset-entries configuration parameter. This can be done using ACL to restrict unprivileged users from using the CONFIG SET command.(CVE-2021-32687)Redis is an open source, in-memory database that persists on disk. The redis-cli command line tool and redis-sentinel service may be vulnerable to integer overflow when parsing specially crafted large multi-bulk network replies. This is a result of a vulnerability in the underlying hiredis library which does not perform an overflow check before calling the calloc() heap allocation function. This issue only impacts systems with heap allocators that do not perform their own overflow checks. Most modern systems do and are therefore not likely to be affected. Furthermore, by default redis-sentinel uses the jemalloc allocator which is also not vulnerable. The problem is fixed in Redis versions 6.2.6, 6.0.16 and 5.0.14.(CVE-2021-32762)Redis is an open source, in-memory database that persists on disk. An integer overflow bug in the underlying string library can be used to corrupt the heap and potentially result with denial of service or remote code execution. The vulnerability involves changing the default proto-max-bulk-len configuration parameter to a very large value and constructing specially crafted network payloads or commands. The problem is fixed in Redis versions 6.2.6, 6.0.16 and 5.0.14. An additional workaround to mitigate the problem without patching the redis-server executable is to prevent users from modifying the proto-max-bulk-len configuration parameter. This can be done using ACL to restrict unprivileged users from using the CONFIG SET command.(CVE-2021-41099)Redis is an in-memory database that persists on disk. By exploiting weaknesses in the Lua script execution environment, an attacker with access to Redis prior to version 7.0.0 or 6.2.7 can inject Lua code that will execute with the (potentially higher) privileges of another Redis user. The Lua script execution environment in Redis provides some measures that prevent a script from creating side effects that persist and can affect the execution of the same, or different script, at a later time. Several weaknesses of these measures have been publicly known for a long time, but they had no security impact as the Redis security model did not endorse the concept of users or privileges. With the introduction of ACLs in Redis 6.0, these weaknesses can be exploited by a less privileged users to inject Lua code that will execute at a later time, when a privileged user executes a Lua script. The problem is fixed in Redis versions 7.0.0 and 6.2.7. An additional workaround to mitigate this problem without patching the redis-server executable, if Lua scripting is not being used, is to block access to `SCRIPT LOAD` and `EVAL` commands using ACL rules.(CVE-2022-24735)Redis is an in-memory database that persists on disk. Prior to versions 6.2.7 and 7.0.0, an attacker attempting to load a specially crafted Lua script can cause NULL pointer dereference which will result with a crash of the redis-server process. The problem is fixed in Redis versions 7.0.0 and 6.2.7. An additional workaround to mitigate this problem without patching the redis-server executable, if Lua scripting is not being used, is to block access to `SCRIPT LOAD` and `EVAL` commands using ACL rules.(CVE-2022-24736)Redis is an in-memory database that persists on disk. Authenticated users issuing specially crafted `SETRANGE` and `SORT(_RO)` commands can trigger an integer overflow, resulting with Redis attempting to allocate impossible amounts of memory and abort with an out-of-memory (OOM) panic. The problem is fixed in Redis versions 7.0.8, 6.2.9 and 6.0.17. Users are advised to upgrade. There are no known workarounds for this vulnerability.(CVE-2022-35977)** DISPUTED ** A vulnerability, which was classified as problematic, was found in Redis up to 6.2.7/7.0.5. Affected is the function sigsegvHandler of the file debug.c of the component Crash Report. The manipulation leads to denial of service. The complexity of an attack is rather high. The exploitability is told to be difficult. The real existence of this vulnerability is still doubted at the moment. Upgrading to version 6.2.8 and 7.0.6 is able to address this issue. The patch is identified as 0bf90d944313919eb8e63d3588bf63a367f020a3. It is recommended to apply a patch to fix this issue. VDB-211962 is the identifier assigned to this vulnerability. NOTE: The vendor claims that this is not a DoS because it applies to the crash logging mechanism which is triggered after a crash has occurred.(CVE-2022-3647)Redis is an in-memory database that persists on disk. Authenticated users issuing specially crafted `SRANDMEMBER`, `ZRANDMEMBER`, and `HRANDFIELD` commands can trigger an integer overflow, resulting in a runtime assertion and termination of the Redis server process. This problem affects all Redis versions. Patches were released in Redis version(s) 6.0.18, 6.2.11 and 7.0.9.(CVE-2023-25155)Redis is an open source, in-memory database that persists on disk. An authenticated user may use a specially crafted Lua script to manipulate the garbage collector and potentially lead to remote code execution. The problem is fixed in 7.4.2, 7.2.7, and 6.2.17. An additional workaround to mitigate the problem without patching the redis-server executable is to prevent users from executing Lua scripts. This can be done using ACL to restrict EVAL and EVALSHA commands.(CVE-2024-46981)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="redis" release="1.oe2203sp4" version="7.2.7">
                         <filename>redis-7.2.7-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="redis-debuginfo" release="1.oe2203sp4" version="7.2.7">
                         <filename>redis-debuginfo-7.2.7-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="redis-debugsource" release="1.oe2203sp4" version="7.2.7">
                         <filename>redis-debugsource-7.2.7-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="redis" release="1.oe2203sp4" version="7.2.7">
                         <filename>redis-7.2.7-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="redis-debuginfo" release="1.oe2203sp4" version="7.2.7">
                         <filename>redis-debuginfo-7.2.7-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="redis-debugsource" release="1.oe2203sp4" version="7.2.7">
                         <filename>redis-debugsource-7.2.7-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1158</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-02-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46782" id="CVE-2024-46782" title="CVE-2024-46782" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47697" id="CVE-2024-47697" title="CVE-2024-47697" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49569" id="CVE-2024-49569" title="CVE-2024-49569" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50125" id="CVE-2024-50125" title="CVE-2024-50125" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50268" id="CVE-2024-50268" title="CVE-2024-50268" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53057" id="CVE-2024-53057" title="CVE-2024-53057" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53096" id="CVE-2024-53096" title="CVE-2024-53096" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53141" id="CVE-2024-53141" title="CVE-2024-53141" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53148" id="CVE-2024-53148" title="CVE-2024-53148" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-53156" id="CVE-2024-53156" title="CVE-2024-53156" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56600" id="CVE-2024-56600" title="CVE-2024-56600" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56601" id="CVE-2024-56601" title="CVE-2024-56601" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56634" id="CVE-2024-56634" title="CVE-2024-56634" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57849" id="CVE-2024-57849" title="CVE-2024-57849" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57900" id="CVE-2024-57900" title="CVE-2024-57900" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21647" id="CVE-2025-21647" title="CVE-2025-21647" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21648" id="CVE-2025-21648" title="CVE-2025-21648" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21667" id="CVE-2025-21667" title="CVE-2025-21667" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:ila: call nf_unregister_net_hooks() soonersyzbot found an use-after-free Read in ila_nf_input [1]Issue here is that ila_xlat_exit_net() frees the rhashtable,then call nf_unregister_net_hooks().It should be done in the reverse way, with a synchronize_rcu().This is a good match for a pre_exit() method.[1] BUG: KASAN: use-after-free in rht_key_hashfn include/linux/rhashtable.h:159 [inline] BUG: KASAN: use-after-free in __rhashtable_lookup include/linux/rhashtable.h:604 [inline] BUG: KASAN: use-after-free in rhashtable_lookup include/linux/rhashtable.h:646 [inline] BUG: KASAN: use-after-free in rhashtable_lookup_fast+0x77a/0x9b0 include/linux/rhashtable.h:672Read of size 4 at addr ffff888064620008 by task ksoftirqd/0/16CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.11.0-rc4-syzkaller-00238-g2ad6d23f465a #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  rht_key_hashfn include/linux/rhashtable.h:159 [inline]  __rhashtable_lookup include/linux/rhashtable.h:604 [inline]  rhashtable_lookup include/linux/rhashtable.h:646 [inline]  rhashtable_lookup_fast+0x77a/0x9b0 include/linux/rhashtable.h:672  ila_lookup_wildcards net/ipv6/ila/ila_xlat.c:132 [inline]  ila_xlat_addr net/ipv6/ila/ila_xlat.c:652 [inline]  ila_nf_input+0x1fe/0x3c0 net/ipv6/ila/ila_xlat.c:190  nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]  nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626  nf_hook include/linux/netfilter.h:269 [inline]  NF_HOOK+0x29e/0x450 include/linux/netfilter.h:312  __netif_receive_skb_one_core net/core/dev.c:5661 [inline]  __netif_receive_skb+0x1ea/0x650 net/core/dev.c:5775  process_backlog+0x662/0x15b0 net/core/dev.c:6108  __napi_poll+0xcb/0x490 net/core/dev.c:6772  napi_poll net/core/dev.c:6841 [inline]  net_rx_action+0x89b/0x1240 net/core/dev.c:6963  handle_softirqs+0x2c4/0x970 kernel/softirq.c:554  run_ksoftirqd+0xca/0x130 kernel/softirq.c:928  smpboot_thread_fn+0x544/0xa30 kernel/smpboot.c:164  kthread+0x2f0/0x390 kernel/kthread.c:389  ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 &lt;/TASK&gt;The buggy address belongs to the physical page:page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x64620flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)page_type: 0xbfffffff(buddy)raw: 00fff00000000000 ffffea0000959608 ffffea00019d9408 0000000000000000raw: 0000000000000000 0000000000000003 00000000bfffffff 0000000000000000page dumped because: kasan: bad access detectedpage_owner tracks the page as freedpage last allocated via order 3, migratetype Unmovable, gfp_mask 0x52dc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_ZERO), pid 5242, tgid 5242 (syz-executor), ts 73611328570, free_ts 618981657187  set_page_owner include/linux/page_owner.h:32 [inline]  post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1493  prep_new_page mm/page_alloc.c:1501 [inline]  get_page_from_freelist+0x2e4c/0x2f10 mm/page_alloc.c:3439  __alloc_pages_noprof+0x256/0x6c0 mm/page_alloc.c:4695  __alloc_pages_node_noprof include/linux/gfp.h:269 [inline]  alloc_pages_node_noprof include/linux/gfp.h:296 [inline]  ___kmalloc_large_node+0x8b/0x1d0 mm/slub.c:4103  __kmalloc_large_node_noprof+0x1a/0x80 mm/slub.c:4130  __do_kmalloc_node mm/slub.c:4146 [inline]  __kmalloc_node_noprof+0x2d2/0x440 mm/slub.c:4164  __kvmalloc_node_noprof+0x72/0x190 mm/util.c:650  bucket_table_alloc lib/rhashtable.c:186 [inline]  rhashtable_init_noprof+0x534/0xa60 lib/rhashtable.c:1071  ila_xlat_init_net+0xa0/0x110 net/ipv6/ila/ila_xlat.c:613  ops_ini---truncated---(CVE-2024-46782)In the Linux kernel, the following vulnerability has been resolved:drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write errorEnsure index in rtl2830_pid_filter does not exceed 31 to preventout-of-bounds access.dev-&gt;filters is a 32-bit value, so set_bit and clear_bit functions shouldonly operate on indices from 0 to 31. If index is 32, it will attempt toaccess a non-existent 33rd bit, leading to out-of-bounds access.Change the boundary check from index &gt; 32 to index &gt;= 32 to resolve thisissue.(CVE-2024-47697)In the Linux kernel, the following vulnerability has been resolved:nvme-rdma: unquiesce admin_q before destroy itKernel will hang on destroy admin_q while we create ctrl failed, suchas following calltrace:PID: 23644    TASK: ff2d52b40f439fc0  CPU: 2    COMMAND: &#34;nvme&#34; #0 [ff61d23de260fb78] __schedule at ffffffff8323bc15 #1 [ff61d23de260fc08] schedule at ffffffff8323c014 #2 [ff61d23de260fc28] blk_mq_freeze_queue_wait at ffffffff82a3dba1 #3 [ff61d23de260fc78] blk_freeze_queue at ffffffff82a4113a #4 [ff61d23de260fc90] blk_cleanup_queue at ffffffff82a33006 #5 [ff61d23de260fcb0] nvme_rdma_destroy_admin_queue at ffffffffc12686ce #6 [ff61d23de260fcc8] nvme_rdma_setup_ctrl at ffffffffc1268ced #7 [ff61d23de260fd28] nvme_rdma_create_ctrl at ffffffffc126919b #8 [ff61d23de260fd68] nvmf_dev_write at ffffffffc024f362 #9 [ff61d23de260fe38] vfs_write at ffffffff827d5f25    RIP: 00007fda7891d574  RSP: 00007ffe2ef06958  RFLAGS: 00000202    RAX: ffffffffffffffda  RBX: 000055e8122a4d90  RCX: 00007fda7891d574    RDX: 000000000000012b  RSI: 000055e8122a4d90  RDI: 0000000000000004    RBP: 00007ffe2ef079c0   R8: 000000000000012b   R9: 000055e8122a4d90    R10: 0000000000000000  R11: 0000000000000202  R12: 0000000000000004    R13: 000055e8122923c0  R14: 000000000000012b  R15: 00007fda78a54500    ORIG_RAX: 0000000000000001  CS: 0033  SS: 002bThis due to we have quiesced admi_q before cancel requests, but forgotto unquiesce before destroy it, as a result we fail to drain thepending requests, and hang on blk_mq_freeze_queue_wait() forever. Heretry to reuse nvme_rdma_teardown_admin_queue() to fix this issue andsimplify the code.(CVE-2024-49569)In the Linux kernel, the following vulnerability has been resolved:Bluetooth: SCO: Fix UAF on sco_sock_timeoutconn-&gt;sk maybe have been unlinked/freed while waiting for sco_conn_lockso this checks if the conn-&gt;sk is still valid by checking if it part ofsco_sk_list.(CVE-2024-50125)In the Linux kernel, the following vulnerability has been resolved:usb: typec: fix potential out of bounds in ucsi_ccg_update_set_new_cam_cmd()The &#34;*cmd&#34; variable can be controlled by the user via debugfs.  That means&#34;new_cam&#34; can be as high as 255 while the size of the uc-&gt;updated[] arrayis UCSI_MAX_ALTMODES (30).The call tree is:ucsi_cmd() // val comes from simple_attr_write_xsigned()-&gt; ucsi_send_command()   -&gt; ucsi_send_command_common()      -&gt; ucsi_run_command() // calls ucsi-&gt;ops-&gt;sync_control()         -&gt; ucsi_ccg_sync_control()(CVE-2024-50268)In the Linux kernel, the following vulnerability has been resolved:net/sched: stop qdisc_tree_reduce_backlog on TC_H_ROOTIn qdisc_tree_reduce_backlog, Qdiscs with major handle ffff: are assumedto be either root or ingress. This assumption is bogus since it&#39;s validto create egress qdiscs with major handle ffff:Budimir Markovic found that for qdiscs like DRR that maintain an activeclass list, it will cause a UAF with a dangling class pointer.In 066a3b5b2346, the concern was to avoid iterating over the ingressqdisc since its parent is itself. The proper fix is to stop when parentTC_H_ROOT is reached because the only way to retrieve ingress is when ahierarchy which does not contain a ffff: major handle call intoqdisc_lookup with TC_H_MAJ(TC_H_ROOT).In the scenario where major ffff: is an egress qdisc in any of the treelevels, the updates will also propagate to TC_H_ROOT, which then theiteration must stop. net/sched/sch_api.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)(CVE-2024-53057)In the Linux kernel, the following vulnerability has been resolved:mm: resolve faulty mmap_region() error path behaviourThe mmap_region() function is somewhat terrifying, with spaghetti-likecontrol flow and numerous means by which issues can arise and incompletestate, memory leaks and other unpleasantness can occur.A large amount of the complexity arises from trying to handle errors latein the process of mapping a VMA, which forms the basis of recentlyobserved issues with resource leaks and observable inconsistent state.Taking advantage of previous patches in this series we move a number ofchecks earlier in the code, simplifying things by moving the core of thelogic into a static internal function __mmap_region().Doing this allows us to perform a number of checks up front before we doany real work, and allows us to unwind the writable unmap checkunconditionally as required and to perform a CONFIG_DEBUG_VM_MAPLE_TREEvalidation unconditionally also.We move a number of things here:1. We preallocate memory for the iterator before we call the file-backed   memory hook, allowing us to exit early and avoid having to perform   complicated and error-prone close/free logic. We carefully free   iterator state on both success and error paths.2. The enclosing mmap_region() function handles the mapping_map_writable()   logic early. Previously the logic had the mapping_map_writable() at the   point of mapping a newly allocated file-backed VMA, and a matching   mapping_unmap_writable() on success and error paths.   We now do this unconditionally if this is a file-backed, shared writable   mapping. If a driver changes the flags to eliminate VM_MAYWRITE, however   doing so does not invalidate the seal check we just performed, and we in   any case always decrement the counter in the wrapper.   We perform a debug assert to ensure a driver does not attempt to do the   opposite.3. We also move arch_validate_flags() up into the mmap_region()   function. This is only relevant on arm64 and sparc64, and the check is   only meaningful for SPARC with ADI enabled. We explicitly add a warning   for this arch if a driver invalidates this check, though the code ought   eventually to be fixed to eliminate the need for this.With all of these measures in place, we no longer need to explicitly closethe VMA on error paths, as we place all checks which might fail prior to acall to any driver mmap hook.This eliminates an entire class of errors, makes the code easier to reasonabout and more robust.(CVE-2024-53096)In the Linux kernel, the following vulnerability has been resolved:netfilter: ipset: add missing range check in bitmap_ip_uadtWhen tb[IPSET_ATTR_IP_TO] is not present but tb[IPSET_ATTR_CIDR] exists,the values of ip and ip_to are slightly swapped. Therefore, the range checkfor ip should be done later, but this part is missing and it seems that thevulnerability occurs.So we should add missing range checks and remove unnecessary range checks.(CVE-2024-53141)In the Linux kernel, the following vulnerability has been resolved:comedi: Flush partial mappings in error caseIf some remap_pfn_range() calls succeeded before one failed, we still havebuffer pages mapped into the userspace page tables when we drop the bufferreference with comedi_buf_map_put(bm). The userspace mappings are onlycleaned up later in the mmap error path.Fix it by explicitly flushing all mappings in our VMA on the error path.See commit 79a61cc3fc04 (&#34;mm: avoid leaving partial pfn mappings around inerror case&#34;).(CVE-2024-53148)In the Linux kernel, the following vulnerability has been resolved:wifi: ath9k: add range check for conn_rsp_epid in htc_connect_service()I found the following bug in my fuzzer:  UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath9k/htc_hst.c:26:51  index 255 is out of range for type &#39;htc_endpoint [22]&#39;  CPU: 0 UID: 0 PID: 8 Comm: kworker/0:0 Not tainted 6.11.0-rc6-dirty #14  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014  Workqueue: events request_firmware_work_func  Call Trace:   &lt;TASK&gt;   dump_stack_lvl+0x180/0x1b0   __ubsan_handle_out_of_bounds+0xd4/0x130   htc_issue_send.constprop.0+0x20c/0x230   ? _raw_spin_unlock_irqrestore+0x3c/0x70   ath9k_wmi_cmd+0x41d/0x610   ? mark_held_locks+0x9f/0xe0   ...Since this bug has been confirmed to be caused by insufficient verificationof conn_rsp_epid, I think it would be appropriate to add a range check forconn_rsp_epid to htc_connect_service() to prevent the bug from occurring.(CVE-2024-53156)In the Linux kernel, the following vulnerability has been resolved:net: inet6: do not leave a dangling sk pointer in inet6_create()sock_init_data() attaches the allocated sk pointer to the provided sockobject. If inet6_create() fails later, the sk object is released, but thesock object retains the dangling sk pointer, which may cause use-after-freelater.Clear the sock sk pointer on error.(CVE-2024-56600)In the Linux kernel, the following vulnerability has been resolved:net: inet: do not leave a dangling sk pointer in inet_create()sock_init_data() attaches the allocated sk object to the provided sockobject. If inet_create() fails later, the sk object is freed, but thesock object retains the dangling pointer, which may create use-after-freelater.Clear the sk pointer in the sock object on error.(CVE-2024-56601)In the Linux kernel, the following vulnerability has been resolved:gpio: grgpio: Add NULL check in grgpio_probedevm_kasprintf() can return a NULL pointer on failure,but thisreturned value in grgpio_probe is not checked.Add NULL check in grgpio_probe, to handle kernel NULLpointer dereference error.(CVE-2024-56634)In the Linux kernel, the following vulnerability has been resolved:s390/cpum_sf: Handle CPU hotplug remove during samplingCPU hotplug remove handling triggers the following functioncall sequence:   CPUHP_AP_PERF_S390_SF_ONLINE  --&gt; s390_pmu_sf_offline_cpu()   ...   CPUHP_AP_PERF_ONLINE          --&gt; perf_event_exit_cpu()The s390 CPUMF sampling CPU hotplug handler invokes: s390_pmu_sf_offline_cpu() +--&gt;  cpusf_pmu_setup()       +--&gt; setup_pmc_cpu()            +--&gt; deallocate_buffers()This function de-allocates all sampling data buffers (SDBs) allocatedfor that CPU at event initialization. It also clears thePMU_F_RESERVED bit. The CPU is gone and can not be sampled.With the event still being active on the removed CPU, the CPU eventhotplug support in kernel performance subsystem triggers thefollowing function calls on the removed CPU:  perf_event_exit_cpu()  +--&gt; perf_event_exit_cpu_context()       +--&gt; __perf_event_exit_context()&#x9;    +--&gt; __perf_remove_from_context()&#x9;         +--&gt; event_sched_out()&#x9;              +--&gt; cpumsf_pmu_del()&#x9;                   +--&gt; cpumsf_pmu_stop()                                +--&gt; hw_perf_event_update()to stop and remove the event. During removal of the event, thesampling device driver tries to read out the remaining samples fromthe sample data buffers (SDBs). But they have already been freed(and may have been re-assigned). This may lead to a use after freesituation in which case the samples are most likely invalid. In thebest case the memory has not been reassigned and still containsvalid data.Remedy this situation and check if the CPU is still in reservedstate (bit PMU_F_RESERVED set). In this case the SDBs have not beenreleased an contain valid data. This is always the case whenthe event is removed (and no CPU hotplug off occured).If the PMU_F_RESERVED bit is not set, the SDB buffers are gone.(CVE-2024-57849)In the Linux kernel, the following vulnerability has been resolved:ila: serialize calls to nf_register_net_hooks()syzbot found a race in ila_add_mapping() [1]commit 031ae72825ce (&#34;ila: call nf_unregister_net_hooks() sooner&#34;)attempted to fix a similar issue.Looking at the syzbot repro, we have concurrent ILA_CMD_ADD commands.Add a mutex to make sure at most one thread is calling nf_register_net_hooks().[1] BUG: KASAN: slab-use-after-free in rht_key_hashfn include/linux/rhashtable.h:159 [inline] BUG: KASAN: slab-use-after-free in __rhashtable_lookup.constprop.0+0x426/0x550 include/linux/rhashtable.h:604Read of size 4 at addr ffff888028f40008 by task dhcpcd/5501CPU: 1 UID: 0 PID: 5501 Comm: dhcpcd Not tainted 6.13.0-rc4-syzkaller-00054-gd6ef8b40d075 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024Call Trace: &lt;IRQ&gt;  __dump_stack lib/dump_stack.c:94 [inline]  dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120  print_address_description mm/kasan/report.c:378 [inline]  print_report+0xc3/0x620 mm/kasan/report.c:489  kasan_report+0xd9/0x110 mm/kasan/report.c:602  rht_key_hashfn include/linux/rhashtable.h:159 [inline]  __rhashtable_lookup.constprop.0+0x426/0x550 include/linux/rhashtable.h:604  rhashtable_lookup include/linux/rhashtable.h:646 [inline]  rhashtable_lookup_fast include/linux/rhashtable.h:672 [inline]  ila_lookup_wildcards net/ipv6/ila/ila_xlat.c:127 [inline]  ila_xlat_addr net/ipv6/ila/ila_xlat.c:652 [inline]  ila_nf_input+0x1ee/0x620 net/ipv6/ila/ila_xlat.c:185  nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]  nf_hook_slow+0xbb/0x200 net/netfilter/core.c:626  nf_hook.constprop.0+0x42e/0x750 include/linux/netfilter.h:269  NF_HOOK include/linux/netfilter.h:312 [inline]  ipv6_rcv+0xa4/0x680 net/ipv6/ip6_input.c:309  __netif_receive_skb_one_core+0x12e/0x1e0 net/core/dev.c:5672  __netif_receive_skb+0x1d/0x160 net/core/dev.c:5785  process_backlog+0x443/0x15f0 net/core/dev.c:6117  __napi_poll.constprop.0+0xb7/0x550 net/core/dev.c:6883  napi_poll net/core/dev.c:6952 [inline]  net_rx_action+0xa94/0x1010 net/core/dev.c:7074  handle_softirqs+0x213/0x8f0 kernel/softirq.c:561  __do_softirq kernel/softirq.c:595 [inline]  invoke_softirq kernel/softirq.c:435 [inline]  __irq_exit_rcu+0x109/0x170 kernel/softirq.c:662  irq_exit_rcu+0x9/0x30 kernel/softirq.c:678  instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline]  sysvec_apic_timer_interrupt+0xa4/0xc0 arch/x86/kernel/apic/apic.c:1049(CVE-2024-57900)In the Linux kernel, the following vulnerability has been resolved:sched: sch_cake: add bounds checks to host bulk flow fairness countsEven though we fixed a logic error in the commit cited below, syzbotstill managed to trigger an underflow of the per-host bulk flowcounters, leading to an out of bounds memory access.To avoid any such logic errors causing out of bounds memory accesses,this commit factors out all accesses to the per-host bulk flow countersto a series of helpers that perform bounds-checking before anyincrements and decrements. This also has the benefit of improvingreadability by moving the conditional checks for the flow mode intothese helpers, instead of having them spread out throughout thecode (which was the cause of the original logic error).As part of this change, the flow quantum calculation is consolidatedinto a helper function, which means that the dithering applied to theost load scaling is now applied both in the DRR rotation and when asparse flow&#39;s quantum is first initiated. The only user-visible effectof this is that the maximum packet size that can be sent while a flowstays sparse will now vary with +/- one byte in some cases. This shouldnot make a noticeable difference in practice, and thus it&#39;s not worthcomplicating the code to preserve the old behaviour.(CVE-2025-21647)In the Linux kernel, the following vulnerability has been resolved:netfilter: conntrack: clamp maximum hashtable size to INT_MAXUse INT_MAX as maximum size for the conntrack hashtable. Otherwise, itis possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof() whenresizing hashtable because __GFP_NOWARN is unset. See:  0708a0afe291 (&#34;mm: Consider __GFP_NOWARN flag for oversized kvmalloc() calls&#34;)Note: hashtable resize is only possible from init_netns.(CVE-2025-21648)In the Linux kernel, the following vulnerability has been resolved:iomap: avoid avoid truncating 64-bit offset to 32 bitson 32-bit kernels, iomap_write_delalloc_scan() was inadvertently using a32-bit position due to folio_next_index() returning an unsigned long.This could lead to an infinite loop when writing to an xfs filesystem.(CVE-2025-21667)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="bpftool" release="250.0.0.154.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-250.0.0.154.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="250.0.0.154.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-250.0.0.154.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="250.0.0.154.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-250.0.0.154.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="250.0.0.154.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-250.0.0.154.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="250.0.0.154.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-250.0.0.154.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="250.0.0.154.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-250.0.0.154.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="250.0.0.154.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-250.0.0.154.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="250.0.0.154.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-250.0.0.154.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="250.0.0.154.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-250.0.0.154.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="250.0.0.154.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-250.0.0.154.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="250.0.0.154.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-250.0.0.154.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="250.0.0.154.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-250.0.0.154.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="250.0.0.154.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-250.0.0.154.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="250.0.0.154.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-250.0.0.154.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="250.0.0.154.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-250.0.0.154.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="250.0.0.154.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-250.0.0.154.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="250.0.0.154.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-250.0.0.154.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="250.0.0.154.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-250.0.0.154.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="250.0.0.154.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-250.0.0.154.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="250.0.0.154.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-250.0.0.154.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="250.0.0.154.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-250.0.0.154.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="250.0.0.154.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-250.0.0.154.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="250.0.0.154.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-250.0.0.154.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="250.0.0.154.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-250.0.0.154.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="250.0.0.154.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-250.0.0.154.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="250.0.0.154.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-250.0.0.154.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="250.0.0.154.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-250.0.0.154.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="250.0.0.154.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-250.0.0.154.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="250.0.0.154.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-250.0.0.154.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="250.0.0.154.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-250.0.0.154.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1164</id>
          <title>An update for json-smart is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-02-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57699" id="CVE-2024-57699" title="CVE-2024-57699" type="cve"></reference>
          </references>
          <description>A security issue was found in Netplex Json-smart 2.5.0 through 2.5.1. When loading a specially crafted JSON input, containing a large number of ’{’, a stack exhaustion can be trigger, which could allow an attacker to cause a Denial of Service (DoS). This issue exists because of an incomplete fix for CVE-2023-1370.(CVE-2024-57699)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="json-smart" release="1.oe2203sp4" version="2.5.2">
                         <filename>json-smart-2.5.2-1.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="json-smart-javadoc" release="1.oe2203sp4" version="2.5.2">
                         <filename>json-smart-javadoc-2.5.2-1.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1165</id>
          <title>An update for emacs is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-02-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1244" id="CVE-2025-1244" title="CVE-2025-1244" type="cve"></reference>
          </references>
          <description>A command injection flaw was found in the text editor Emacs. It could allow a remote, unauthenticated attacker to execute arbitrary shell commands on a vulnerable system. Exploitation is possible by tricking users into visiting a specially crafted website or an HTTP URL with a redirect.(CVE-2025-1244)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="emacs" release="15.oe2203sp4" version="27.2">
                         <filename>emacs-27.2-15.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="emacs-common" release="15.oe2203sp4" version="27.2">
                         <filename>emacs-common-27.2-15.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="emacs-debuginfo" release="15.oe2203sp4" version="27.2">
                         <filename>emacs-debuginfo-27.2-15.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="emacs-debugsource" release="15.oe2203sp4" version="27.2">
                         <filename>emacs-debugsource-27.2-15.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="emacs-devel" release="15.oe2203sp4" version="27.2">
                         <filename>emacs-devel-27.2-15.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="emacs-lucid" release="15.oe2203sp4" version="27.2">
                         <filename>emacs-lucid-27.2-15.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="emacs-nox" release="15.oe2203sp4" version="27.2">
                         <filename>emacs-nox-27.2-15.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="emacs-filesystem" release="15.oe2203sp4" version="27.2">
                         <filename>emacs-filesystem-27.2-15.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="emacs-help" release="15.oe2203sp4" version="27.2">
                         <filename>emacs-help-27.2-15.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="emacs-terminal" release="15.oe2203sp4" version="27.2">
                         <filename>emacs-terminal-27.2-15.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="emacs" release="15.oe2203sp4" version="27.2">
                         <filename>emacs-27.2-15.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="emacs-common" release="15.oe2203sp4" version="27.2">
                         <filename>emacs-common-27.2-15.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="emacs-debuginfo" release="15.oe2203sp4" version="27.2">
                         <filename>emacs-debuginfo-27.2-15.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="emacs-debugsource" release="15.oe2203sp4" version="27.2">
                         <filename>emacs-debugsource-27.2-15.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="emacs-devel" release="15.oe2203sp4" version="27.2">
                         <filename>emacs-devel-27.2-15.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="emacs-lucid" release="15.oe2203sp4" version="27.2">
                         <filename>emacs-lucid-27.2-15.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="emacs-nox" release="15.oe2203sp4" version="27.2">
                         <filename>emacs-nox-27.2-15.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1166</id>
          <title>An update for vim is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-02-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-22134" id="CVE-2025-22134" title="CVE-2025-22134" type="cve"></reference>
          </references>
          <description>When switching to other buffers using the :all command and visual mode still being active, this may cause a heap-buffer overflow, because Vim does not properly end visual mode and therefore may try to access beyond the end of a line in a buffer. In Patch 9.1.1003 Vim will correctly reset the visual mode before opening other windows and buffers and therefore fix this bug. In addition it does verify that it won&#39;t try to access a position if the position is greater than the corresponding buffer line. Impact is medium since the user must have switched on visual mode when executing the :all ex command. The Vim project would like to thank github user gandalf4a for reporting this issue. The issue has been fixed as of Vim patch v9.1.1003(CVE-2025-22134)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="2" arch="aarch64" name="vim-X11" release="31.oe2203sp4" version="9.0">
                         <filename>vim-X11-9.0-31.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-common" release="31.oe2203sp4" version="9.0">
                         <filename>vim-common-9.0-31.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-debuginfo" release="31.oe2203sp4" version="9.0">
                         <filename>vim-debuginfo-9.0-31.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-debugsource" release="31.oe2203sp4" version="9.0">
                         <filename>vim-debugsource-9.0-31.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-enhanced" release="31.oe2203sp4" version="9.0">
                         <filename>vim-enhanced-9.0-31.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-minimal" release="31.oe2203sp4" version="9.0">
                         <filename>vim-minimal-9.0-31.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="noarch" name="vim-filesystem" release="31.oe2203sp4" version="9.0">
                         <filename>vim-filesystem-9.0-31.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-X11" release="31.oe2203sp4" version="9.0">
                         <filename>vim-X11-9.0-31.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-common" release="31.oe2203sp4" version="9.0">
                         <filename>vim-common-9.0-31.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-debuginfo" release="31.oe2203sp4" version="9.0">
                         <filename>vim-debuginfo-9.0-31.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-debugsource" release="31.oe2203sp4" version="9.0">
                         <filename>vim-debugsource-9.0-31.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-enhanced" release="31.oe2203sp4" version="9.0">
                         <filename>vim-enhanced-9.0-31.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-minimal" release="31.oe2203sp4" version="9.0">
                         <filename>vim-minimal-9.0-31.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1170</id>
          <title>An update for etcd is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2025-02-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-28235" id="CVE-2021-28235" title="CVE-2021-28235" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3064" id="CVE-2022-3064" title="CVE-2022-3064" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34038" id="CVE-2022-34038" title="CVE-2022-34038" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41723" id="CVE-2022-41723" title="CVE-2022-41723" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32082" id="CVE-2023-32082" title="CVE-2023-32082" type="cve"></reference>
          </references>
          <description>Authentication vulnerability found in Etcd-io v.3.4.10 allows remote attackers to escalate privileges via the debug function.(CVE-2021-28235)Parsing malicious or large YAML documents can consume excessive amounts of CPU or memory.(CVE-2022-3064)Etcd v3.5.4 allows remote attackers to cause a denial of service via function PageWriter.write in pagewriter.go. NOTE: the vendor&#39;s position is that this is not a vulnerability.(CVE-2022-34038)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)etcd is a distributed key-value store for the data of a distributed system. Prior to versions 3.4.26 and 3.5.9, the LeaseTimeToLive API allows access to key names (not value) associated to a lease when `Keys` parameter is true, even a user doesn&#39;t have read permission to the keys. The impact is limited to a cluster which enables auth (RBAC). Versions 3.4.26 and 3.5.9 fix this issue. There are no known workarounds.(CVE-2023-32082)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="etcd" release="11.oe2203sp4" version="3.4.14">
                         <filename>etcd-3.4.14-11.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="etcd" release="11.oe2203sp4" version="3.4.14">
                         <filename>etcd-3.4.14-11.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1171</id>
          <title>An update for microcode_ctl is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-02-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34440" id="CVE-2023-34440" title="CVE-2023-34440" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-43758" id="CVE-2023-43758" title="CVE-2023-43758" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24582" id="CVE-2024-24582" title="CVE-2024-24582" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-28047" id="CVE-2024-28047" title="CVE-2024-28047" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-28127" id="CVE-2024-28127" title="CVE-2024-28127" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29214" id="CVE-2024-29214" title="CVE-2024-29214" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-31068" id="CVE-2024-31068" title="CVE-2024-31068" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-31157" id="CVE-2024-31157" title="CVE-2024-31157" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36293" id="CVE-2024-36293" title="CVE-2024-36293" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-37020" id="CVE-2024-37020" title="CVE-2024-37020" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39279" id="CVE-2024-39279" title="CVE-2024-39279" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39355" id="CVE-2024-39355" title="CVE-2024-39355" type="cve"></reference>
          </references>
          <description>Improper input validation in UEFI firmware for some Intel(R) Processors may allow a privileged user to potentially enable escalation of privilege via local access.(CVE-2023-34440)Improper input validation in UEFI firmware for some Intel(R) processors may allow a privileged user to potentially enable escalation of privilege via local access.(CVE-2023-43758)Improper input validation in XmlCli feature for UEFI firmware for some Intel(R) processors may allow privileged user to potentially enable escalation of privilege via local access.(CVE-2024-24582)Improper input validation in UEFI firmware for some Intel(R) Processors may allow a privileged user to potentially enable information disclosure via local access.(CVE-2024-28047)Improper input validation in UEFI firmware for some Intel(R) Processors may allow a privileged user to potentially enable escalation of privilege via local access.(CVE-2024-28127)Improper input validation in UEFI firmware CseVariableStorageSmm for some Intel(R) Processors may allow a privileged user to potentially enable escalation of privilege via local access.(CVE-2024-29214)Improper Finite State Machines (FSMs) in Hardware Logic for some Intel(R) Processors may allow privileged user to potentially enable denial of service via local access.(CVE-2024-31068)Improper initialization in UEFI firmware OutOfBandXML module in some Intel(R) Processors may allow a privileged user to potentially enable information disclosure via local access.(CVE-2024-31157)Improper access control in the EDECCSSA user leaf function for some Intel(R) Processors with Intel(R) SGX may allow an authenticated user to potentially enable denial of service via local access.(CVE-2024-36293)Sequence of processor instructions leads to unexpected behavior in the Intel(R) DSA V1.0 for some Intel(R) Xeon(R) Processors may allow an authenticated user to potentially enable denial of service via local access.(CVE-2024-37020)Insufficient granularity of access control in UEFI firmware in some Intel(R) processors may allow a authenticated user to potentially enable denial of service via local access.(CVE-2024-39279)Improper handling of physical or environmental conditions in some Intel(R) Processors may allow an authenticated user to enable denial of service via local access.(CVE-2024-39355)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="x86_64" name="microcode_ctl" release="1.oe2203sp4" version="20250211">
                         <filename>microcode_ctl-20250211-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1175</id>
          <title>An update for gnutls is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-02-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-12243" id="CVE-2024-12243" title="CVE-2024-12243" type="cve"></reference>
          </references>
          <description>A flaw was found in GnuTLS, which relies on libtasn1 for ASN.1 data processing. Due to an inefficient algorithm in libtasn1, decoding certain DER-encoded certificate data can take excessive time, leading to increased resource consumption. This flaw allows a remote attacker to send a specially crafted certificate, causing GnuTLS to become unresponsive or slow, resulting in a denial-of-service condition.(CVE-2024-12243)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="gnutls" release="16.oe2203sp4" version="3.7.2">
                         <filename>gnutls-3.7.2-16.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gnutls-debuginfo" release="16.oe2203sp4" version="3.7.2">
                         <filename>gnutls-debuginfo-3.7.2-16.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gnutls-debugsource" release="16.oe2203sp4" version="3.7.2">
                         <filename>gnutls-debugsource-3.7.2-16.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gnutls-devel" release="16.oe2203sp4" version="3.7.2">
                         <filename>gnutls-devel-3.7.2-16.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gnutls-utils" release="16.oe2203sp4" version="3.7.2">
                         <filename>gnutls-utils-3.7.2-16.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="gnutls-help" release="16.oe2203sp4" version="3.7.2">
                         <filename>gnutls-help-3.7.2-16.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gnutls" release="16.oe2203sp4" version="3.7.2">
                         <filename>gnutls-3.7.2-16.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gnutls-debuginfo" release="16.oe2203sp4" version="3.7.2">
                         <filename>gnutls-debuginfo-3.7.2-16.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gnutls-debugsource" release="16.oe2203sp4" version="3.7.2">
                         <filename>gnutls-debugsource-3.7.2-16.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gnutls-devel" release="16.oe2203sp4" version="3.7.2">
                         <filename>gnutls-devel-3.7.2-16.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gnutls-utils" release="16.oe2203sp4" version="3.7.2">
                         <filename>gnutls-utils-3.7.2-16.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1177</id>
          <title>An update for elfutils is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-02-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1352" id="CVE-2025-1352" title="CVE-2025-1352" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1372" id="CVE-2025-1372" title="CVE-2025-1372" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1376" id="CVE-2025-1376" title="CVE-2025-1376" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1377" id="CVE-2025-1377" title="CVE-2025-1377" type="cve"></reference>
          </references>
          <description>A vulnerability has been found in GNU elfutils 0.192 and classified as critical. This vulnerability affects the function __libdw_thread_tail in the library libdw_alloc.c of the component eu-readelf. The manipulation of the argument w leads to memory corruption. The attack can be initiated remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. The name of the patch is 2636426a091bd6c6f7f02e49ab20d4cdc6bfc753. It is recommended to apply a patch to fix this issue.(CVE-2025-1352)A vulnerability was found in GNU elfutils 0.192. It has been declared as critical. Affected by this vulnerability is the function dump_data_section/print_string_section of the file readelf.c of the component eu-readelf. The manipulation of the argument z/x leads to buffer overflow. An attack has to be approached locally. The exploit has been disclosed to the public and may be used. The identifier of the patch is 73db9d2021cab9e23fd734b0a76a612d52a6f1db. It is recommended to apply a patch to fix this issue.(CVE-2025-1372)A vulnerability classified as problematic was found in GNU elfutils 0.192. This vulnerability affects the function elf_strptr in the library /libelf/elf_strptr.c of the component eu-strip. The manipulation leads to denial of service. It is possible to launch the attack on the local host. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. The name of the patch is b16f441cca0a4841050e3215a9f120a6d8aea918. It is recommended to apply a patch to fix this issue.(CVE-2025-1376)A vulnerability, which was classified as problematic, has been found in GNU elfutils 0.192. This issue affects the function gelf_getsymshndx of the file strip.c of the component eu-strip. The manipulation leads to denial of service. The attack needs to be approached locally. The exploit has been disclosed to the public and may be used. The identifier of the patch is fbf1df9ca286de3323ae541973b08449f8d03aba. It is recommended to apply a patch to fix this issue.(CVE-2025-1377)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="elfutils" release="20.oe2203sp4" version="0.185">
                         <filename>elfutils-0.185-20.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="elfutils-debuginfo" release="20.oe2203sp4" version="0.185">
                         <filename>elfutils-debuginfo-0.185-20.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="elfutils-debuginfod" release="20.oe2203sp4" version="0.185">
                         <filename>elfutils-debuginfod-0.185-20.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="elfutils-debuginfod-client" release="20.oe2203sp4" version="0.185">
                         <filename>elfutils-debuginfod-client-0.185-20.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="elfutils-debuginfod-client-devel" release="20.oe2203sp4" version="0.185">
                         <filename>elfutils-debuginfod-client-devel-0.185-20.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="elfutils-debugsource" release="20.oe2203sp4" version="0.185">
                         <filename>elfutils-debugsource-0.185-20.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="elfutils-devel" release="20.oe2203sp4" version="0.185">
                         <filename>elfutils-devel-0.185-20.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="elfutils-extra" release="20.oe2203sp4" version="0.185">
                         <filename>elfutils-extra-0.185-20.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="elfutils-help" release="20.oe2203sp4" version="0.185">
                         <filename>elfutils-help-0.185-20.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="elfutils" release="20.oe2203sp4" version="0.185">
                         <filename>elfutils-0.185-20.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="elfutils-debuginfo" release="20.oe2203sp4" version="0.185">
                         <filename>elfutils-debuginfo-0.185-20.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="elfutils-debuginfod" release="20.oe2203sp4" version="0.185">
                         <filename>elfutils-debuginfod-0.185-20.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="elfutils-debuginfod-client" release="20.oe2203sp4" version="0.185">
                         <filename>elfutils-debuginfod-client-0.185-20.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="elfutils-debuginfod-client-devel" release="20.oe2203sp4" version="0.185">
                         <filename>elfutils-debuginfod-client-devel-0.185-20.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="elfutils-debugsource" release="20.oe2203sp4" version="0.185">
                         <filename>elfutils-debugsource-0.185-20.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="elfutils-devel" release="20.oe2203sp4" version="0.185">
                         <filename>elfutils-devel-0.185-20.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="elfutils-extra" release="20.oe2203sp4" version="0.185">
                         <filename>elfutils-extra-0.185-20.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="elfutils-help" release="20.oe2203sp4" version="0.185">
                         <filename>elfutils-help-0.185-20.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1183</id>
          <title>An update for etcd is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-02-28"></issued>
          <references>
               <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-44487" id="CVE-2023-44487" title="CVE-2023-44487" 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)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="etcd" release="12.oe2203sp4" version="3.4.14">
                         <filename>etcd-3.4.14-12.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="etcd" release="12.oe2203sp4" version="3.4.14">
                         <filename>etcd-3.4.14-12.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1189</id>
          <title>An update for grafana is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-02-28"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-31097" id="CVE-2022-31097" title="CVE-2022-31097" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-31123" id="CVE-2022-31123" title="CVE-2022-31123" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-31130" id="CVE-2022-31130" title="CVE-2022-31130" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-35957" id="CVE-2022-35957" title="CVE-2022-35957" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-36062" id="CVE-2022-36062" title="CVE-2022-36062" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-39201" id="CVE-2022-39201" title="CVE-2022-39201" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-39306" id="CVE-2022-39306" title="CVE-2022-39306" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-39307" id="CVE-2022-39307" title="CVE-2022-39307" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-39324" id="CVE-2022-39324" title="CVE-2022-39324" type="cve"></reference>
          </references>
          <description>Grafana is an open-source platform for monitoring and observability. Versions on the 8.x and 9.x branch prior to 9.0.3, 8.5.9, 8.4.10, and 8.3.10 are vulnerable to stored cross-site scripting via the Unified Alerting feature of Grafana. An attacker can exploit this vulnerability to escalate privilege from editor to admin by tricking an authenticated admin to click on a link. Versions 9.0.3, 8.5.9, 8.4.10, and 8.3.10 contain a patch. As a workaround, it is possible to disable alerting or use legacy alerting.(CVE-2022-31097)Grafana is an open source observability and data visualization platform. Versions prior to 9.1.8 and 8.5.14 are vulnerable to a bypass in the plugin signature verification. An attacker can convince a server admin to download and successfully run a malicious plugin even though unsigned plugins are not allowed. Versions 9.1.8 and 8.5.14 contain a patch for this issue. As a workaround, do not install plugins downloaded from untrusted sources.(CVE-2022-31123)Grafana is an open source observability and data visualization platform. Versions of Grafana for endpoints prior to 9.1.8 and 8.5.14 could leak authentication tokens to some destination plugins under some conditions. The vulnerability impacts data source and plugin proxy endpoints with authentication tokens. The destination plugin could receive a user&#39;s Grafana authentication token. Versions 9.1.8 and 8.5.14 contain a patch for this issue. As a workaround, do not use API keys, JWT authentication, or any HTTP Header based authentication.(CVE-2022-31130)Grafana is an open-source platform for monitoring and observability. Versions prior to 9.1.6 and 8.5.13 are vulnerable to an escalation from admin to server admin when auth proxy is used, allowing an admin to take over the server admin account and gain full control of the grafana instance. All installations should be upgraded as soon as possible. As a workaround deactivate auth proxy following the instructions at: https://grafana.com/docs/grafana/latest/setup-grafana/configure-security/configure-authentication/auth-proxy/(CVE-2022-35957)Grafana is an open-source platform for monitoring and observability. In versions prior to 8.5.13, 9.0.9, and 9.1.6, Grafana is subject to Improper Preservation of Permissions resulting in privilege escalation on some folders where Admin is the only used permission. The vulnerability impacts Grafana instances where RBAC was disabled and enabled afterwards, as the migrations which are translating legacy folder permissions to RBAC permissions do not account for the scenario where the only user permission in the folder is Admin, as a result RBAC adds permissions for Editors and Viewers which allow them to edit and view folders accordingly. This issue has been patched in versions 8.5.13, 9.0.9, and 9.1.6. A workaround when the impacted folder/dashboard is known is to remove the additional permissions manually.(CVE-2022-36062)Grafana is an open source observability and data visualization platform. Starting with version 5.0.0-beta1 and prior to versions 8.5.14 and 9.1.8, Grafana could leak the authentication cookie of users to plugins. The vulnerability impacts data source and plugin proxy endpoints under certain conditions. The destination plugin could receive a user&#39;s Grafana authentication cookie. Versions 9.1.8 and 8.5.14 contain a patch for this issue. There are no known workarounds.(CVE-2022-39201)Grafana is an open-source platform for monitoring and observability. Versions prior to 9.2.4, or 8.5.15 on the 8.X branch, are subject to Improper Input Validation. Grafana admins can invite other members to the organization they are an admin for. When admins add members to the organization, non existing users get an email invite, existing members are added directly to the organization. When an invite link is sent, it allows users to sign up with whatever username/email address the user chooses and become a member of the organization. This introduces a vulnerability which can be used with malicious intent. This issue is patched in version 9.2.4, and has been backported to 8.5.15. There are no known workarounds.(CVE-2022-39306)Grafana is an open-source platform for monitoring and observability. When using the forget password on the login page, a POST request is made to the `/api/user/password/sent-reset-email` URL. When the username or email does not exist, a JSON response contains a “user not found” message. This leaks information to unauthenticated users and introduces a security risk. This issue has been patched in 9.2.4 and backported to 8.5.15. There are no known workarounds.(CVE-2022-39307)Grafana is an open-source platform for monitoring and observability. Prior to versions 8.5.16 and 9.2.8, malicious user can create a snapshot and arbitrarily choose the `originalUrl` parameter by editing the query, thanks to a web proxy. When another user opens the URL of the snapshot, they will be presented with the regular web interface delivered by the trusted Grafana server. The `Open original dashboard` button no longer points to the to the real original dashboard but to the attacker’s injected URL. This issue is fixed in versions 8.5.16 and 9.2.8.(CVE-2022-39324)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="grafana" release="1.oe2203sp4" version="9.2.10">
                         <filename>grafana-9.2.10-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="grafana-debuginfo" release="1.oe2203sp4" version="9.2.10">
                         <filename>grafana-debuginfo-9.2.10-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="grafana-debugsource" release="1.oe2203sp4" version="9.2.10">
                         <filename>grafana-debugsource-9.2.10-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="grafana-selinux" release="1.oe2203sp4" version="9.2.10">
                         <filename>grafana-selinux-9.2.10-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="grafana" release="1.oe2203sp4" version="9.2.10">
                         <filename>grafana-9.2.10-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="grafana-debuginfo" release="1.oe2203sp4" version="9.2.10">
                         <filename>grafana-debuginfo-9.2.10-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="grafana-debugsource" release="1.oe2203sp4" version="9.2.10">
                         <filename>grafana-debugsource-9.2.10-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="grafana-selinux" release="1.oe2203sp4" version="9.2.10">
                         <filename>grafana-selinux-9.2.10-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1190</id>
          <title>An update for edk2 is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-02-28"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-13176" id="CVE-2024-13176" title="CVE-2024-13176" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4741" id="CVE-2024-4741" title="CVE-2024-4741" type="cve"></reference>
          </references>
          <description>Issue summary: A timing side-channel which could potentially allow recoveringthe private key exists in the ECDSA signature computation.Impact summary: A timing side-channel in ECDSA signature computationscould allow recovering the private key by an attacker. However, measuringthe timing would require either local access to the signing application ora very fast network connection with low latency.There is a timing signal of around 300 nanoseconds when the top word ofthe inverted ECDSA nonce value is zero. This can happen with significantprobability only for some of the supported elliptic curves. In particularthe NIST P-521 curve is affected. To be able to measure this leak, the attackerprocess must either be located in the same physical computer or musthave a very fast network connection with low latency. For that reasonthe severity of this vulnerability is Low.(CVE-2024-13176)Issue summary: Calling the OpenSSL API function SSL_free_buffers may causememory to be accessed that was previously freed in some situationsImpact summary: A use after free can have a range of potential consequences suchas the corruption of valid data, crashes or execution of arbitrary code.However, only applications that directly call the SSL_free_buffers function areaffected by this issue. Applications that do not call this function are notvulnerable. Our investigations indicate that this function is rarely used byapplications.The SSL_free_buffers function is used to free the internal OpenSSL buffer usedwhen processing an incoming record from the network. The call is only expectedto succeed if the buffer is not currently in use. However, two scenarios havebeen identified where the buffer is freed even when still in use.The first scenario occurs where a record header has been received from thenetwork and processed by OpenSSL, but the full record body has not yet arrived.In this case calling SSL_free_buffers will succeed even though a record has onlybeen partially processed and the buffer is still in use.The second scenario occurs where a full record containing application data hasbeen received and processed by OpenSSL but the application has only read part ofthis data. Again a call to SSL_free_buffers will succeed even though the bufferis still in use.While these scenarios could occur accidentally during normal operation amalicious attacker could attempt to engineer a stituation where this occurs.We are not aware of this issue being actively exploited.The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.(CVE-2024-4741)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="edk2-debuginfo" release="23.oe2203sp4" version="202011">
                         <filename>edk2-debuginfo-202011-23.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="edk2-debugsource" release="23.oe2203sp4" version="202011">
                         <filename>edk2-debugsource-202011-23.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="edk2-devel" release="23.oe2203sp4" version="202011">
                         <filename>edk2-devel-202011-23.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-aarch64" release="23.oe2203sp4" version="202011">
                         <filename>edk2-aarch64-202011-23.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-help" release="23.oe2203sp4" version="202011">
                         <filename>edk2-help-202011-23.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-ovmf" release="23.oe2203sp4" version="202011">
                         <filename>edk2-ovmf-202011-23.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-edk2-devel" release="23.oe2203sp4" version="202011">
                         <filename>python3-edk2-devel-202011-23.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-debuginfo" release="23.oe2203sp4" version="202011">
                         <filename>edk2-debuginfo-202011-23.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-debugsource" release="23.oe2203sp4" version="202011">
                         <filename>edk2-debugsource-202011-23.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-devel" release="23.oe2203sp4" version="202011">
                         <filename>edk2-devel-202011-23.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1203</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-02-28"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-50150" id="CVE-2024-50150" title="CVE-2024-50150" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56650" id="CVE-2024-56650" title="CVE-2024-56650" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56658" id="CVE-2024-56658" title="CVE-2024-56658" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56754" id="CVE-2024-56754" title="CVE-2024-56754" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57792" id="CVE-2024-57792" title="CVE-2024-57792" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57795" id="CVE-2024-57795" title="CVE-2024-57795" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57857" id="CVE-2024-57857" title="CVE-2024-57857" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:usb: typec: altmode should keep reference to parentThe altmode device release refers to its parent device, but without keepinga reference to it.When registering the altmode, get a reference to the parent and put it inthe release function.Before this fix, when using CONFIG_DEBUG_KOBJECT_RELEASE, we see issueslike this:[   43.572860] kobject: &#39;port0.0&#39; (ffff8880057ba008): kobject_release, parent 0000000000000000 (delayed 3000)[   43.573532] kobject: &#39;port0.1&#39; (ffff8880057bd008): kobject_release, parent 0000000000000000 (delayed 1000)[   43.574407] kobject: &#39;port0&#39; (ffff8880057b9008): kobject_release, parent 0000000000000000 (delayed 3000)[   43.575059] kobject: &#39;port1.0&#39; (ffff8880057ca008): kobject_release, parent 0000000000000000 (delayed 4000)[   43.575908] kobject: &#39;port1.1&#39; (ffff8880057c9008): kobject_release, parent 0000000000000000 (delayed 4000)[   43.576908] kobject: &#39;typec&#39; (ffff8880062dbc00): kobject_release, parent 0000000000000000 (delayed 4000)[   43.577769] kobject: &#39;port1&#39; (ffff8880057bf008): kobject_release, parent 0000000000000000 (delayed 3000)[   46.612867] ==================================================================[   46.613402] BUG: KASAN: slab-use-after-free in typec_altmode_release+0x38/0x129[   46.614003] Read of size 8 at addr ffff8880057b9118 by task kworker/2:1/48[   46.614538][   46.614668] CPU: 2 UID: 0 PID: 48 Comm: kworker/2:1 Not tainted 6.12.0-rc1-00138-gedbae730ad31 #535[   46.615391] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014[   46.616042] Workqueue: events kobject_delayed_cleanup[   46.616446] Call Trace:[   46.616648]  &lt;TASK&gt;[   46.616820]  dump_stack_lvl+0x5b/0x7c[   46.617112]  ? typec_altmode_release+0x38/0x129[   46.617470]  print_report+0x14c/0x49e[   46.617769]  ? rcu_read_unlock_sched+0x56/0x69[   46.618117]  ? __virt_addr_valid+0x19a/0x1ab[   46.618456]  ? kmem_cache_debug_flags+0xc/0x1d[   46.618807]  ? typec_altmode_release+0x38/0x129[   46.619161]  kasan_report+0x8d/0xb4[   46.619447]  ? typec_altmode_release+0x38/0x129[   46.619809]  ? process_scheduled_works+0x3cb/0x85f[   46.620185]  typec_altmode_release+0x38/0x129[   46.620537]  ? process_scheduled_works+0x3cb/0x85f[   46.620907]  device_release+0xaf/0xf2[   46.621206]  kobject_delayed_cleanup+0x13b/0x17a[   46.621584]  process_scheduled_works+0x4f6/0x85f[   46.621955]  ? __pfx_process_scheduled_works+0x10/0x10[   46.622353]  ? hlock_class+0x31/0x9a[   46.622647]  ? lock_acquired+0x361/0x3c3[   46.622956]  ? move_linked_works+0x46/0x7d[   46.623277]  worker_thread+0x1ce/0x291[   46.623582]  ? __kthread_parkme+0xc8/0xdf[   46.623900]  ? __pfx_worker_thread+0x10/0x10[   46.624236]  kthread+0x17e/0x190[   46.624501]  ? kthread+0xfb/0x190[   46.624756]  ? __pfx_kthread+0x10/0x10[   46.625015]  ret_from_fork+0x20/0x40[   46.625268]  ? __pfx_kthread+0x10/0x10[   46.625532]  ret_from_fork_asm+0x1a/0x30[   46.625805]  &lt;/TASK&gt;[   46.625953][   46.626056] Allocated by task 678:[   46.626287]  kasan_save_stack+0x24/0x44[   46.626555]  kasan_save_track+0x14/0x2d[   46.626811]  __kasan_kmalloc+0x3f/0x4d[   46.627049]  __kmalloc_noprof+0x1bf/0x1f0[   46.627362]  typec_register_port+0x23/0x491[   46.627698]  cros_typec_probe+0x634/0xbb6[   46.628026]  platform_probe+0x47/0x8c[   46.628311]  really_probe+0x20a/0x47d[   46.628605]  device_driver_attach+0x39/0x72[   46.628940]  bind_store+0x87/0xd7[   46.629213]  kernfs_fop_write_iter+0x1aa/0x218[   46.629574]  vfs_write+0x1d6/0x29b[   46.629856]  ksys_write+0xcd/0x13b[   46.630128]  do_syscall_64+0xd4/0x139[   46.630420]  entry_SYSCALL_64_after_hwframe+0x76/0x7e[   46.630820][   46.630946] Freed by task 48:[   46.631182]  kasan_save_stack+0x24/0x44[   46.631493]  kasan_save_track+0x14/0x2d[   46.631799]  kasan_save_free_info+0x3f/0x4d[   46.632144]  __kasan_slab_free+0x37/0x45[   46.632474]---truncated---(CVE-2024-50150)In the Linux kernel, the following vulnerability has been resolved:netfilter: x_tables: fix LED ID check in led_tg_check()Syzbot has reported the following BUG detected by KASAN:BUG: KASAN: slab-out-of-bounds in strlen+0x58/0x70Read of size 1 at addr ffff8881022da0c8 by task repro/5879...Call Trace: &lt;TASK&gt; dump_stack_lvl+0x241/0x360 ? __pfx_dump_stack_lvl+0x10/0x10 ? __pfx__printk+0x10/0x10 ? _printk+0xd5/0x120 ? __virt_addr_valid+0x183/0x530 ? __virt_addr_valid+0x183/0x530 print_report+0x169/0x550 ? __virt_addr_valid+0x183/0x530 ? __virt_addr_valid+0x183/0x530 ? __virt_addr_valid+0x45f/0x530 ? __phys_addr+0xba/0x170 ? strlen+0x58/0x70 kasan_report+0x143/0x180 ? strlen+0x58/0x70 strlen+0x58/0x70 kstrdup+0x20/0x80 led_tg_check+0x18b/0x3c0 xt_check_target+0x3bb/0xa40 ? __pfx_xt_check_target+0x10/0x10 ? stack_depot_save_flags+0x6e4/0x830 ? nft_target_init+0x174/0xc30 nft_target_init+0x82d/0xc30 ? __pfx_nft_target_init+0x10/0x10 ? nf_tables_newrule+0x1609/0x2980 ? nf_tables_newrule+0x1609/0x2980 ? rcu_is_watching+0x15/0xb0 ? nf_tables_newrule+0x1609/0x2980 ? nf_tables_newrule+0x1609/0x2980 ? __kmalloc_noprof+0x21a/0x400 nf_tables_newrule+0x1860/0x2980 ? __pfx_nf_tables_newrule+0x10/0x10 ? __nla_parse+0x40/0x60 nfnetlink_rcv+0x14e5/0x2ab0 ? __pfx_validate_chain+0x10/0x10 ? __pfx_nfnetlink_rcv+0x10/0x10 ? __lock_acquire+0x1384/0x2050 ? netlink_deliver_tap+0x2e/0x1b0 ? __pfx_lock_release+0x10/0x10 ? netlink_deliver_tap+0x2e/0x1b0 netlink_unicast+0x7f8/0x990 ? __pfx_netlink_unicast+0x10/0x10 ? __virt_addr_valid+0x183/0x530 ? __check_object_size+0x48e/0x900 netlink_sendmsg+0x8e4/0xcb0 ? __pfx_netlink_sendmsg+0x10/0x10 ? aa_sock_msg_perm+0x91/0x160 ? __pfx_netlink_sendmsg+0x10/0x10 __sock_sendmsg+0x223/0x270 ____sys_sendmsg+0x52a/0x7e0 ? __pfx_____sys_sendmsg+0x10/0x10 __sys_sendmsg+0x292/0x380 ? __pfx___sys_sendmsg+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x43d/0x780 ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10 ? exc_page_fault+0x590/0x8c0 ? do_syscall_64+0xb6/0x230 do_syscall_64+0xf3/0x230 entry_SYSCALL_64_after_hwframe+0x77/0x7f... &lt;/TASK&gt;Since an invalid (without &#39;\0&#39; byte at all) byte sequence may be passedfrom userspace, add an extra check to ensure that such a sequence isrejected as possible ID and so never passed to &#39;kstrdup()&#39; and further.(CVE-2024-56650)In the Linux kernel, the following vulnerability has been resolved:net: defer final &#39;struct net&#39; free in netns dismantleIlya reported a slab-use-after-free in dst_destroy [1]Issue is in xfrm6_net_init() and xfrm4_net_init() :They copy xfrm[46]_dst_ops_template into net-&gt;xfrm.xfrm[46]_dst_ops.But net structure might be freed before all the dst callbacks arecalled. So when dst_destroy() calls later :if (dst-&gt;ops-&gt;destroy)    dst-&gt;ops-&gt;destroy(dst);dst-&gt;ops points to the old net-&gt;xfrm.xfrm[46]_dst_ops, which has been freed.See a relevant issue fixed in :ac888d58869b (&#34;net: do not delay dst_entries_add() in dst_release()&#34;)A fix is to queue the &#39;struct net&#39; to be freed after oneanother cleanup_net() round (and existing rcu_barrier())[1]BUG: KASAN: slab-use-after-free in dst_destroy (net/core/dst.c:112)Read of size 8 at addr ffff8882137ccab0 by task swapper/37/0Dec 03 05:46:18 kernel:CPU: 37 UID: 0 PID: 0 Comm: swapper/37 Kdump: loaded Not tainted 6.12.0 #67Hardware name: Red Hat KVM/RHEL, BIOS 1.16.1-1.el9 04/01/2014Call Trace: &lt;IRQ&gt;dump_stack_lvl (lib/dump_stack.c:124)print_address_description.constprop.0 (mm/kasan/report.c:378)? dst_destroy (net/core/dst.c:112)print_report (mm/kasan/report.c:489)? dst_destroy (net/core/dst.c:112)? kasan_addr_to_slab (mm/kasan/common.c:37)kasan_report (mm/kasan/report.c:603)? dst_destroy (net/core/dst.c:112)? rcu_do_batch (kernel/rcu/tree.c:2567)dst_destroy (net/core/dst.c:112)rcu_do_batch (kernel/rcu/tree.c:2567)? __pfx_rcu_do_batch (kernel/rcu/tree.c:2491)? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4339 kernel/locking/lockdep.c:4406)rcu_core (kernel/rcu/tree.c:2825)handle_softirqs (kernel/softirq.c:554)__irq_exit_rcu (kernel/softirq.c:589 kernel/softirq.c:428 kernel/softirq.c:637)irq_exit_rcu (kernel/softirq.c:651)sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1049 arch/x86/kernel/apic/apic.c:1049) &lt;/IRQ&gt; &lt;TASK&gt;asm_sysvec_apic_timer_interrupt (./arch/x86/include/asm/idtentry.h:702)RIP: 0010:default_idle (./arch/x86/include/asm/irqflags.h:37 ./arch/x86/include/asm/irqflags.h:92 arch/x86/kernel/process.c:743)Code: 00 4d 29 c8 4c 01 c7 4c 29 c2 e9 6e ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 90 0f 00 2d c7 c9 27 00 fb f4 &lt;fa&gt; c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90RSP: 0018:ffff888100d2fe00 EFLAGS: 00000246RAX: 00000000001870ed RBX: 1ffff110201a5fc2 RCX: ffffffffb61a3e46RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffb3d4d123RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed11c7e1835dR10: ffff888e3f0c1aeb R11: 0000000000000000 R12: 0000000000000000R13: ffff888100d20000 R14: dffffc0000000000 R15: 0000000000000000? ct_kernel_exit.constprop.0 (kernel/context_tracking.c:148)? cpuidle_idle_call (kernel/sched/idle.c:186)default_idle_call (./include/linux/cpuidle.h:143 kernel/sched/idle.c:118)cpuidle_idle_call (kernel/sched/idle.c:186)? __pfx_cpuidle_idle_call (kernel/sched/idle.c:168)? lock_release (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5848)? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4347 kernel/locking/lockdep.c:4406)? tsc_verify_tsc_adjust (arch/x86/kernel/tsc_sync.c:59)do_idle (kernel/sched/idle.c:326)cpu_startup_entry (kernel/sched/idle.c:423 (discriminator 1))start_secondary (arch/x86/kernel/smpboot.c:202 arch/x86/kernel/smpboot.c:282)? __pfx_start_secondary (arch/x86/kernel/smpboot.c:232)? soft_restart_cpu (arch/x86/kernel/head_64.S:452)common_startup_64 (arch/x86/kernel/head_64.S:414) &lt;/TASK&gt;Dec 03 05:46:18 kernel:Allocated by task 12184:kasan_save_stack (mm/kasan/common.c:48)kasan_save_track (./arch/x86/include/asm/current.h:49 mm/kasan/common.c:60 mm/kasan/common.c:69)__kasan_slab_alloc (mm/kasan/common.c:319 mm/kasan/common.c:345)kmem_cache_alloc_noprof (mm/slub.c:4085 mm/slub.c:4134 mm/slub.c:4141)copy_net_ns (net/core/net_namespace.c:421 net/core/net_namespace.c:480)create_new_namespaces---truncated---(CVE-2024-56658)In the Linux kernel, the following vulnerability has been resolved:crypto: caam - Fix the pointer passed to caam_qi_shutdown()The type of the last parameter given to devm_add_action_or_reset() is&#34;struct caam_drv_private *&#34;, but in caam_qi_shutdown(), it is casted to&#34;struct device *&#34;.Pass the correct parameter to devm_add_action_or_reset() so that theresources are released as expected.(CVE-2024-56754)In the Linux kernel, the following vulnerability has been resolved:power: supply: gpio-charger: Fix set charge current limitsFix set charge current limits for devices which allow to set the lowestcharge current limit to be greater zero. If requested charge current limitis below lowest limit, the index equals current_limit_map_size which leadsto accessing memory beyond allocated memory.(CVE-2024-57792)In the Linux kernel, the following vulnerability has been resolved:RDMA/rxe: Remove the direct link to net_deviceThe similar patch in siw is in the link:https://git.kernel.org/rdma/rdma/c/16b87037b48889This problem also occurred in RXE. The following analyze this problem.In the following Call Traces:&#34;BUG: KASAN: slab-use-after-free in dev_get_flags+0x188/0x1d0 net/core/dev.c:8782Read of size 4 at addr ffff8880554640b0 by task kworker/1:4/5295CPU: 1 UID: 0 PID: 5295 Comm: kworker/1:4 Not tainted6.12.0-rc3-syzkaller-00399-g9197b73fd7bb #0Hardware name: Google Compute Engine/Google Compute Engine,BIOS Google 09/13/2024Workqueue: infiniband ib_cache_event_taskCall Trace: &lt;TASK&gt; __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 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 dev_get_flags+0x188/0x1d0 net/core/dev.c:8782 rxe_query_port+0x12d/0x260 drivers/infiniband/sw/rxe/rxe_verbs.c:60 __ib_query_port drivers/infiniband/core/device.c:2111 [inline] ib_query_port+0x168/0x7d0 drivers/infiniband/core/device.c:2143 ib_cache_update+0x1a9/0xb80 drivers/infiniband/core/cache.c:1494 ib_cache_event_task+0xf3/0x1e0 drivers/infiniband/core/cache.c:1568 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa65/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f2/0x390 kernel/kthread.c:389 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 &lt;/TASK&gt;&#34;1). In the link [1],&#34; infiniband syz2: set down&#34;This means that on 839.350575, the event ib_cache_event_task was sent andiqueued in ib_wq.2). In the link [1],&#34; team0 (unregistering): Port device team_slave_0 removed&#34;It indicates that before 843.251853, the net device should be freed.3). In the link [1],&#34; BUG: KASAN: slab-use-after-free in dev_get_flags+0x188/0x1d0&#34;This means that on 850.559070, this slab-use-after-free problem occurred.In all, on 839.350575, the event ib_cache_event_task was sent and queuedin ib_wq,before 843.251853, the net device veth was freed.on 850.559070, this event was executed, and the mentioned freed net devicewas called. Thus, the above call trace occurred.[1] https://syzkaller.appspot.com/x/log.txt?x=12e7025f980000(CVE-2024-57795)In the Linux kernel, the following vulnerability has been resolved:RDMA/siw: Remove direct link to net_deviceDo not manage a per device direct link to net_device. Relyon associated ib_devices net_device management, not doublingthe effort locally. A badly managed local link to net_devicewas causing a &#39;KASAN: slab-use-after-free&#39; exception duringsiw_query_port() call.(CVE-2024-57857)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="bpftool" release="251.0.0.155.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-251.0.0.155.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="251.0.0.155.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-251.0.0.155.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="251.0.0.155.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-251.0.0.155.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="251.0.0.155.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-251.0.0.155.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="251.0.0.155.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-251.0.0.155.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="251.0.0.155.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-251.0.0.155.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="251.0.0.155.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-251.0.0.155.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="251.0.0.155.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-251.0.0.155.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="251.0.0.155.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-251.0.0.155.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="251.0.0.155.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-251.0.0.155.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="251.0.0.155.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-251.0.0.155.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="251.0.0.155.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-251.0.0.155.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="251.0.0.155.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-251.0.0.155.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="251.0.0.155.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-251.0.0.155.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="251.0.0.155.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-251.0.0.155.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="251.0.0.155.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-251.0.0.155.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="251.0.0.155.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-251.0.0.155.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="251.0.0.155.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-251.0.0.155.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="251.0.0.155.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-251.0.0.155.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="251.0.0.155.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-251.0.0.155.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="251.0.0.155.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-251.0.0.155.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="251.0.0.155.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-251.0.0.155.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="251.0.0.155.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-251.0.0.155.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="251.0.0.155.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-251.0.0.155.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="251.0.0.155.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-251.0.0.155.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="251.0.0.155.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-251.0.0.155.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="251.0.0.155.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-251.0.0.155.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="251.0.0.155.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-251.0.0.155.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="251.0.0.155.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-251.0.0.155.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="251.0.0.155.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-251.0.0.155.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1206</id>
          <title>An update for ceph is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-02-28"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-48916" id="CVE-2024-48916" title="CVE-2024-48916" type="cve"></reference>
          </references>
          <description>A vulnerability in the Ceph Rados Gateway (RadosGW) OIDC provider allows attackers to bypass JWT signature verification by supplying a token with &#34;none&#34; as the algorithm (alg). This occurs because the implementation fails to enforce strict signature validation, enabling attackers to forge valid tokens without a signature.(CVE-2024-48916)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="2" arch="aarch64" name="ceph" release="22.oe2203sp4" version="16.2.7">
                         <filename>ceph-16.2.7-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="ceph-base" release="22.oe2203sp4" version="16.2.7">
                         <filename>ceph-base-16.2.7-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="ceph-common" release="22.oe2203sp4" version="16.2.7">
                         <filename>ceph-common-16.2.7-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="ceph-debuginfo" release="22.oe2203sp4" version="16.2.7">
                         <filename>ceph-debuginfo-16.2.7-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="ceph-debugsource" release="22.oe2203sp4" version="16.2.7">
                         <filename>ceph-debugsource-16.2.7-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="ceph-fuse" release="22.oe2203sp4" version="16.2.7">
                         <filename>ceph-fuse-16.2.7-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="ceph-immutable-object-cache" release="22.oe2203sp4" version="16.2.7">
                         <filename>ceph-immutable-object-cache-16.2.7-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="ceph-mds" release="22.oe2203sp4" version="16.2.7">
                         <filename>ceph-mds-16.2.7-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="ceph-mgr" release="22.oe2203sp4" version="16.2.7">
                         <filename>ceph-mgr-16.2.7-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="ceph-mon" release="22.oe2203sp4" version="16.2.7">
                         <filename>ceph-mon-16.2.7-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="ceph-osd" release="22.oe2203sp4" version="16.2.7">
                         <filename>ceph-osd-16.2.7-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="ceph-radosgw" release="22.oe2203sp4" version="16.2.7">
                         <filename>ceph-radosgw-16.2.7-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="ceph-resource-agents" release="22.oe2203sp4" version="16.2.7">
                         <filename>ceph-resource-agents-16.2.7-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="ceph-selinux" release="22.oe2203sp4" version="16.2.7">
                         <filename>ceph-selinux-16.2.7-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="ceph-test" release="22.oe2203sp4" version="16.2.7">
                         <filename>ceph-test-16.2.7-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="cephfs-mirror" release="22.oe2203sp4" version="16.2.7">
                         <filename>cephfs-mirror-16.2.7-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="libcephfs-devel" release="22.oe2203sp4" version="16.2.7">
                         <filename>libcephfs-devel-16.2.7-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="libcephfs2" release="22.oe2203sp4" version="16.2.7">
                         <filename>libcephfs2-16.2.7-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="libcephsqlite" release="22.oe2203sp4" version="16.2.7">
                         <filename>libcephsqlite-16.2.7-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="libcephsqlite-devel" release="22.oe2203sp4" version="16.2.7">
                         <filename>libcephsqlite-devel-16.2.7-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="librados-devel" release="22.oe2203sp4" version="16.2.7">
                         <filename>librados-devel-16.2.7-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="librados2" release="22.oe2203sp4" version="16.2.7">
                         <filename>librados2-16.2.7-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="libradospp-devel" release="22.oe2203sp4" version="16.2.7">
                         <filename>libradospp-devel-16.2.7-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="libradosstriper-devel" release="22.oe2203sp4" version="16.2.7">
                         <filename>libradosstriper-devel-16.2.7-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="libradosstriper1" release="22.oe2203sp4" version="16.2.7">
                         <filename>libradosstriper1-16.2.7-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="librbd-devel" release="22.oe2203sp4" version="16.2.7">
                         <filename>librbd-devel-16.2.7-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="librbd1" release="22.oe2203sp4" version="16.2.7">
                         <filename>librbd1-16.2.7-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="librgw-devel" release="22.oe2203sp4" version="16.2.7">
                         <filename>librgw-devel-16.2.7-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="librgw2" release="22.oe2203sp4" version="16.2.7">
                         <filename>librgw2-16.2.7-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="python3-ceph-argparse" release="22.oe2203sp4" version="16.2.7">
                         <filename>python3-ceph-argparse-16.2.7-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="python3-ceph-common" release="22.oe2203sp4" version="16.2.7">
                         <filename>python3-ceph-common-16.2.7-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="python3-cephfs" release="22.oe2203sp4" version="16.2.7">
                         <filename>python3-cephfs-16.2.7-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="python3-rados" release="22.oe2203sp4" version="16.2.7">
                         <filename>python3-rados-16.2.7-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="python3-rbd" release="22.oe2203sp4" version="16.2.7">
                         <filename>python3-rbd-16.2.7-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="python3-rgw" release="22.oe2203sp4" version="16.2.7">
                         <filename>python3-rgw-16.2.7-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="rados-objclass-devel" release="22.oe2203sp4" version="16.2.7">
                         <filename>rados-objclass-devel-16.2.7-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="rbd-fuse" release="22.oe2203sp4" version="16.2.7">
                         <filename>rbd-fuse-16.2.7-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="rbd-mirror" release="22.oe2203sp4" version="16.2.7">
                         <filename>rbd-mirror-16.2.7-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="rbd-nbd" release="22.oe2203sp4" version="16.2.7">
                         <filename>rbd-nbd-16.2.7-22.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="noarch" name="ceph-grafana-dashboards" release="22.oe2203sp4" version="16.2.7">
                         <filename>ceph-grafana-dashboards-16.2.7-22.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="2" arch="noarch" name="ceph-mgr-cephadm" release="22.oe2203sp4" version="16.2.7">
                         <filename>ceph-mgr-cephadm-16.2.7-22.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="2" arch="noarch" name="ceph-mgr-dashboard" release="22.oe2203sp4" version="16.2.7">
                         <filename>ceph-mgr-dashboard-16.2.7-22.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="2" arch="noarch" name="ceph-mgr-diskprediction-local" release="22.oe2203sp4" version="16.2.7">
                         <filename>ceph-mgr-diskprediction-local-16.2.7-22.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="2" arch="noarch" name="ceph-mgr-k8sevents" release="22.oe2203sp4" version="16.2.7">
                         <filename>ceph-mgr-k8sevents-16.2.7-22.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="2" arch="noarch" name="ceph-mgr-modules-core" release="22.oe2203sp4" version="16.2.7">
                         <filename>ceph-mgr-modules-core-16.2.7-22.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="2" arch="noarch" name="ceph-mgr-rook" release="22.oe2203sp4" version="16.2.7">
                         <filename>ceph-mgr-rook-16.2.7-22.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="2" arch="noarch" name="ceph-prometheus-alerts" release="22.oe2203sp4" version="16.2.7">
                         <filename>ceph-prometheus-alerts-16.2.7-22.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="2" arch="noarch" name="cephadm" release="22.oe2203sp4" version="16.2.7">
                         <filename>cephadm-16.2.7-22.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="2" arch="noarch" name="cephfs-top" release="22.oe2203sp4" version="16.2.7">
                         <filename>cephfs-top-16.2.7-22.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="ceph" release="22.oe2203sp4" version="16.2.7">
                         <filename>ceph-16.2.7-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="ceph-base" release="22.oe2203sp4" version="16.2.7">
                         <filename>ceph-base-16.2.7-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="ceph-common" release="22.oe2203sp4" version="16.2.7">
                         <filename>ceph-common-16.2.7-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="ceph-debuginfo" release="22.oe2203sp4" version="16.2.7">
                         <filename>ceph-debuginfo-16.2.7-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="ceph-debugsource" release="22.oe2203sp4" version="16.2.7">
                         <filename>ceph-debugsource-16.2.7-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="ceph-fuse" release="22.oe2203sp4" version="16.2.7">
                         <filename>ceph-fuse-16.2.7-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="ceph-immutable-object-cache" release="22.oe2203sp4" version="16.2.7">
                         <filename>ceph-immutable-object-cache-16.2.7-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="ceph-mds" release="22.oe2203sp4" version="16.2.7">
                         <filename>ceph-mds-16.2.7-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="ceph-mgr" release="22.oe2203sp4" version="16.2.7">
                         <filename>ceph-mgr-16.2.7-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="ceph-mon" release="22.oe2203sp4" version="16.2.7">
                         <filename>ceph-mon-16.2.7-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="ceph-osd" release="22.oe2203sp4" version="16.2.7">
                         <filename>ceph-osd-16.2.7-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="ceph-radosgw" release="22.oe2203sp4" version="16.2.7">
                         <filename>ceph-radosgw-16.2.7-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="ceph-resource-agents" release="22.oe2203sp4" version="16.2.7">
                         <filename>ceph-resource-agents-16.2.7-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="ceph-selinux" release="22.oe2203sp4" version="16.2.7">
                         <filename>ceph-selinux-16.2.7-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="ceph-test" release="22.oe2203sp4" version="16.2.7">
                         <filename>ceph-test-16.2.7-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="cephfs-mirror" release="22.oe2203sp4" version="16.2.7">
                         <filename>cephfs-mirror-16.2.7-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="libcephfs-devel" release="22.oe2203sp4" version="16.2.7">
                         <filename>libcephfs-devel-16.2.7-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="libcephfs2" release="22.oe2203sp4" version="16.2.7">
                         <filename>libcephfs2-16.2.7-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="libcephsqlite" release="22.oe2203sp4" version="16.2.7">
                         <filename>libcephsqlite-16.2.7-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="libcephsqlite-devel" release="22.oe2203sp4" version="16.2.7">
                         <filename>libcephsqlite-devel-16.2.7-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="librados-devel" release="22.oe2203sp4" version="16.2.7">
                         <filename>librados-devel-16.2.7-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="librados2" release="22.oe2203sp4" version="16.2.7">
                         <filename>librados2-16.2.7-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="libradospp-devel" release="22.oe2203sp4" version="16.2.7">
                         <filename>libradospp-devel-16.2.7-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="libradosstriper-devel" release="22.oe2203sp4" version="16.2.7">
                         <filename>libradosstriper-devel-16.2.7-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="libradosstriper1" release="22.oe2203sp4" version="16.2.7">
                         <filename>libradosstriper1-16.2.7-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="librbd-devel" release="22.oe2203sp4" version="16.2.7">
                         <filename>librbd-devel-16.2.7-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="librbd1" release="22.oe2203sp4" version="16.2.7">
                         <filename>librbd1-16.2.7-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="librgw-devel" release="22.oe2203sp4" version="16.2.7">
                         <filename>librgw-devel-16.2.7-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="librgw2" release="22.oe2203sp4" version="16.2.7">
                         <filename>librgw2-16.2.7-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="python3-ceph-argparse" release="22.oe2203sp4" version="16.2.7">
                         <filename>python3-ceph-argparse-16.2.7-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="python3-ceph-common" release="22.oe2203sp4" version="16.2.7">
                         <filename>python3-ceph-common-16.2.7-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="python3-cephfs" release="22.oe2203sp4" version="16.2.7">
                         <filename>python3-cephfs-16.2.7-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="python3-rados" release="22.oe2203sp4" version="16.2.7">
                         <filename>python3-rados-16.2.7-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="python3-rbd" release="22.oe2203sp4" version="16.2.7">
                         <filename>python3-rbd-16.2.7-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="python3-rgw" release="22.oe2203sp4" version="16.2.7">
                         <filename>python3-rgw-16.2.7-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="rados-objclass-devel" release="22.oe2203sp4" version="16.2.7">
                         <filename>rados-objclass-devel-16.2.7-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="rbd-fuse" release="22.oe2203sp4" version="16.2.7">
                         <filename>rbd-fuse-16.2.7-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="rbd-mirror" release="22.oe2203sp4" version="16.2.7">
                         <filename>rbd-mirror-16.2.7-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="rbd-nbd" release="22.oe2203sp4" version="16.2.7">
                         <filename>rbd-nbd-16.2.7-22.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1211</id>
          <title>An update for uboot-tools is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-02-28"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57254" id="CVE-2024-57254" title="CVE-2024-57254" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57255" id="CVE-2024-57255" title="CVE-2024-57255" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57256" id="CVE-2024-57256" title="CVE-2024-57256" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57257" id="CVE-2024-57257" title="CVE-2024-57257" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57258" id="CVE-2024-57258" title="CVE-2024-57258" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57259" id="CVE-2024-57259" title="CVE-2024-57259" type="cve"></reference>
          </references>
          <description>An integer overflow in sqfs_inode_size in Das U-Boot before 2025.01-rc1 occurs in the symlink size calculation via a crafted squashfs filesystem.(CVE-2024-57254)An integer overflow in sqfs_resolve_symlink in Das U-Boot before 2025.01-rc1 occurs via a crafted squashfs filesystem with an inode size of 0xffffffff, resulting in a malloc of zero and resultant memory overwrite.(CVE-2024-57255)An integer overflow in ext4fs_read_symlink in Das U-Boot before 2025.01-rc1 occurs for zalloc (adding one to an le32 variable) via a crafted ext4 filesystem with an inode size of 0xffffffff, resulting in a malloc of zero and resultant memory overwrite.(CVE-2024-57256)A stack consumption issue in sqfs_size in Das U-Boot before 2025.01-rc1 occurs via a crafted squashfs filesystem with deep symlink nesting.(CVE-2024-57257)Integer overflows in memory allocation in Das U-Boot before 2025.01-rc1 occur for a crafted squashfs filesystem via sbrk, via request2size, or because ptrdiff_t is mishandled on x86_64.(CVE-2024-57258)sqfs_search_dir in Das U-Boot before 2025.01-rc1 exhibits an off-by-one error and resultant heap memory corruption for squashfs directory listing because the path separator is not considered in a size calculation.(CVE-2024-57259)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="uboot-images-elf" release="9.oe2203sp4" version="2021.10">
                         <filename>uboot-images-elf-2021.10-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="uboot-tools" release="9.oe2203sp4" version="2021.10">
                         <filename>uboot-tools-2021.10-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="uboot-tools-debuginfo" release="9.oe2203sp4" version="2021.10">
                         <filename>uboot-tools-debuginfo-2021.10-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="uboot-tools-debugsource" release="9.oe2203sp4" version="2021.10">
                         <filename>uboot-tools-debugsource-2021.10-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="uboot-images-armv8" release="9.oe2203sp4" version="2021.10">
                         <filename>uboot-images-armv8-2021.10-9.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="uboot-tools-help" release="9.oe2203sp4" version="2021.10">
                         <filename>uboot-tools-help-2021.10-9.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="uboot-tools" release="9.oe2203sp4" version="2021.10">
                         <filename>uboot-tools-2021.10-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="uboot-tools-debuginfo" release="9.oe2203sp4" version="2021.10">
                         <filename>uboot-tools-debuginfo-2021.10-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="uboot-tools-debugsource" release="9.oe2203sp4" version="2021.10">
                         <filename>uboot-tools-debugsource-2021.10-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1215</id>
          <title>An update for bind is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-02-28"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-11187" id="CVE-2024-11187" title="CVE-2024-11187" type="cve"></reference>
          </references>
          <description>It is possible to construct a zone such that some queries to it will generate responses containing numerous records in the Additional section. An attacker sending many such queries can cause either the authoritative server itself or an independent resolver to use disproportionate resources processing the queries. Zones will usually need to have been deliberately crafted to attack this exposure.This issue affects BIND 9 versions 9.11.0 through 9.11.37, 9.16.0 through 9.16.50, 9.18.0 through 9.18.32, 9.20.0 through 9.20.4, 9.21.0 through 9.21.3, 9.11.3-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.50-S1, and 9.18.11-S1 through 9.18.32-S1.(CVE-2024-11187)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="32" arch="aarch64" name="bind" release="24.oe2203sp4" version="9.16.23">
                         <filename>bind-9.16.23-24.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-chroot" release="24.oe2203sp4" version="9.16.23">
                         <filename>bind-chroot-9.16.23-24.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-debuginfo" release="24.oe2203sp4" version="9.16.23">
                         <filename>bind-debuginfo-9.16.23-24.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-debugsource" release="24.oe2203sp4" version="9.16.23">
                         <filename>bind-debugsource-9.16.23-24.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-devel" release="24.oe2203sp4" version="9.16.23">
                         <filename>bind-devel-9.16.23-24.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-dnssec-utils" release="24.oe2203sp4" version="9.16.23">
                         <filename>bind-dnssec-utils-9.16.23-24.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-libs" release="24.oe2203sp4" version="9.16.23">
                         <filename>bind-libs-9.16.23-24.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-pkcs11" release="24.oe2203sp4" version="9.16.23">
                         <filename>bind-pkcs11-9.16.23-24.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-pkcs11-devel" release="24.oe2203sp4" version="9.16.23">
                         <filename>bind-pkcs11-devel-9.16.23-24.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-pkcs11-libs" release="24.oe2203sp4" version="9.16.23">
                         <filename>bind-pkcs11-libs-9.16.23-24.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-pkcs11-utils" release="24.oe2203sp4" version="9.16.23">
                         <filename>bind-pkcs11-utils-9.16.23-24.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-utils" release="24.oe2203sp4" version="9.16.23">
                         <filename>bind-utils-9.16.23-24.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="noarch" name="bind-dnssec-doc" release="24.oe2203sp4" version="9.16.23">
                         <filename>bind-dnssec-doc-9.16.23-24.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="32" arch="noarch" name="bind-license" release="24.oe2203sp4" version="9.16.23">
                         <filename>bind-license-9.16.23-24.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="32" arch="noarch" name="python3-bind" release="24.oe2203sp4" version="9.16.23">
                         <filename>python3-bind-9.16.23-24.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind" release="24.oe2203sp4" version="9.16.23">
                         <filename>bind-9.16.23-24.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-chroot" release="24.oe2203sp4" version="9.16.23">
                         <filename>bind-chroot-9.16.23-24.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-debuginfo" release="24.oe2203sp4" version="9.16.23">
                         <filename>bind-debuginfo-9.16.23-24.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-debugsource" release="24.oe2203sp4" version="9.16.23">
                         <filename>bind-debugsource-9.16.23-24.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-devel" release="24.oe2203sp4" version="9.16.23">
                         <filename>bind-devel-9.16.23-24.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-dnssec-utils" release="24.oe2203sp4" version="9.16.23">
                         <filename>bind-dnssec-utils-9.16.23-24.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-libs" release="24.oe2203sp4" version="9.16.23">
                         <filename>bind-libs-9.16.23-24.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-pkcs11" release="24.oe2203sp4" version="9.16.23">
                         <filename>bind-pkcs11-9.16.23-24.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-pkcs11-devel" release="24.oe2203sp4" version="9.16.23">
                         <filename>bind-pkcs11-devel-9.16.23-24.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-pkcs11-libs" release="24.oe2203sp4" version="9.16.23">
                         <filename>bind-pkcs11-libs-9.16.23-24.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-pkcs11-utils" release="24.oe2203sp4" version="9.16.23">
                         <filename>bind-pkcs11-utils-9.16.23-24.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-utils" release="24.oe2203sp4" version="9.16.23">
                         <filename>bind-utils-9.16.23-24.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1219</id>
          <title>An update for abseil-cpp is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-02-28"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-0838" id="CVE-2025-0838" title="CVE-2025-0838" type="cve"></reference>
          </references>
          <description>There exists a heap buffer overflow vulnerable in Abseil-cpp. The sized constructors, reserve(), and rehash() methods of absl::{flat,node}hash{set,map} did not impose an upper bound on their size argument. As a result, it was possible for a caller to pass a very large size that would cause an integer overflow when computing the size of the container&#39;s backing store, and a subsequent out-of-bounds memory write. Subsequent accesses to the container might also access out-of-bounds memory. We recommend upgrading past commit 5a0e2cb5e3958dd90bb8569a2766622cb74d90c1(CVE-2025-0838)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="abseil-cpp" release="6.oe2203sp4" version="20220623.1">
                         <filename>abseil-cpp-20220623.1-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="abseil-cpp-debuginfo" release="6.oe2203sp4" version="20220623.1">
                         <filename>abseil-cpp-debuginfo-20220623.1-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="abseil-cpp-debugsource" release="6.oe2203sp4" version="20220623.1">
                         <filename>abseil-cpp-debugsource-20220623.1-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="abseil-cpp-devel" release="6.oe2203sp4" version="20220623.1">
                         <filename>abseil-cpp-devel-20220623.1-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="abseil-cpp" release="6.oe2203sp4" version="20220623.1">
                         <filename>abseil-cpp-20220623.1-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="abseil-cpp-debuginfo" release="6.oe2203sp4" version="20220623.1">
                         <filename>abseil-cpp-debuginfo-20220623.1-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="abseil-cpp-debugsource" release="6.oe2203sp4" version="20220623.1">
                         <filename>abseil-cpp-debugsource-20220623.1-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="abseil-cpp-devel" release="6.oe2203sp4" version="20220623.1">
                         <filename>abseil-cpp-devel-20220623.1-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1220</id>
          <title>An update for erlang is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-02-28"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-26618" id="CVE-2025-26618" title="CVE-2025-26618" type="cve"></reference>
          </references>
          <description>Erlang is a programming language and runtime system for building massively scalable soft real-time systems with requirements on high availability. OTP is a set of Erlang libraries, which consists of the Erlang runtime system, a number of ready-to-use components mainly written in Erlang. Packet size is not verified properly for SFTP packets. As a result when multiple SSH packets (conforming to max SSH packet size) are received by ssh, they might be combined into an SFTP packet which will exceed the max allowed packet size and potentially cause large amount of memory to be allocated. Note that situation described above can only happen for successfully authenticated users after completing the SSH handshake. This issue has been patched in OTP versions 27.2.4, 26.2.5.9, and 25.3.2.18. There are no known workarounds for this vulnerability.(CVE-2025-26618)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="erlang" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-23.3.4.9-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-asn1" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-asn1-23.3.4.9-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-common_test" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-common_test-23.3.4.9-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-compiler" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-compiler-23.3.4.9-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-crypto" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-crypto-23.3.4.9-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-debugger" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-debugger-23.3.4.9-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-debuginfo" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-debuginfo-23.3.4.9-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-debugsource" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-debugsource-23.3.4.9-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-dialyzer" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-dialyzer-23.3.4.9-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-diameter" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-diameter-23.3.4.9-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-edoc" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-edoc-23.3.4.9-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-eldap" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-eldap-23.3.4.9-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-erl_docgen" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-erl_docgen-23.3.4.9-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-erl_interface" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-erl_interface-23.3.4.9-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-erts" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-erts-23.3.4.9-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-et" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-et-23.3.4.9-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-eunit" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-eunit-23.3.4.9-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-examples" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-examples-23.3.4.9-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-ftp" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-ftp-23.3.4.9-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-hipe" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-hipe-23.3.4.9-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-inets" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-inets-23.3.4.9-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-jinterface" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-jinterface-23.3.4.9-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-kernel" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-kernel-23.3.4.9-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-megaco" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-megaco-23.3.4.9-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-mnesia" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-mnesia-23.3.4.9-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-observer" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-observer-23.3.4.9-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-odbc" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-odbc-23.3.4.9-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-os_mon" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-os_mon-23.3.4.9-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-parsetools" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-parsetools-23.3.4.9-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-public_key" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-public_key-23.3.4.9-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-reltool" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-reltool-23.3.4.9-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-runtime_tools" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-runtime_tools-23.3.4.9-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-sasl" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-sasl-23.3.4.9-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-snmp" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-snmp-23.3.4.9-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-ssh" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-ssh-23.3.4.9-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-ssl" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-ssl-23.3.4.9-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-stdlib" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-stdlib-23.3.4.9-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-syntax_tools" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-syntax_tools-23.3.4.9-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-tftp" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-tftp-23.3.4.9-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-tools" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-tools-23.3.4.9-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-wx" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-wx-23.3.4.9-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-xmerl" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-xmerl-23.3.4.9-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-23.3.4.9-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-asn1" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-asn1-23.3.4.9-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-common_test" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-common_test-23.3.4.9-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-compiler" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-compiler-23.3.4.9-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-crypto" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-crypto-23.3.4.9-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-debugger" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-debugger-23.3.4.9-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-debuginfo" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-debuginfo-23.3.4.9-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-debugsource" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-debugsource-23.3.4.9-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-dialyzer" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-dialyzer-23.3.4.9-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-diameter" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-diameter-23.3.4.9-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-edoc" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-edoc-23.3.4.9-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-eldap" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-eldap-23.3.4.9-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-erl_docgen" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-erl_docgen-23.3.4.9-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-erl_interface" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-erl_interface-23.3.4.9-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-erts" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-erts-23.3.4.9-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-et" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-et-23.3.4.9-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-eunit" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-eunit-23.3.4.9-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-examples" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-examples-23.3.4.9-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-ftp" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-ftp-23.3.4.9-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-hipe" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-hipe-23.3.4.9-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-inets" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-inets-23.3.4.9-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-jinterface" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-jinterface-23.3.4.9-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-kernel" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-kernel-23.3.4.9-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-megaco" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-megaco-23.3.4.9-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-mnesia" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-mnesia-23.3.4.9-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-observer" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-observer-23.3.4.9-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-odbc" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-odbc-23.3.4.9-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-os_mon" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-os_mon-23.3.4.9-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-parsetools" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-parsetools-23.3.4.9-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-public_key" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-public_key-23.3.4.9-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-reltool" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-reltool-23.3.4.9-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-runtime_tools" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-runtime_tools-23.3.4.9-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-sasl" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-sasl-23.3.4.9-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-snmp" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-snmp-23.3.4.9-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-ssh" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-ssh-23.3.4.9-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-ssl" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-ssl-23.3.4.9-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-stdlib" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-stdlib-23.3.4.9-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-syntax_tools" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-syntax_tools-23.3.4.9-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-tftp" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-tftp-23.3.4.9-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-tools" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-tools-23.3.4.9-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-wx" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-wx-23.3.4.9-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-xmerl" release="5.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-xmerl-23.3.4.9-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1225</id>
          <title>An update for libxml2 is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-02-28"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56171" id="CVE-2024-56171" title="CVE-2024-56171" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-24928" id="CVE-2025-24928" title="CVE-2025-24928" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-27113" id="CVE-2025-27113" title="CVE-2025-27113" type="cve"></reference>
          </references>
          <description>libxml2 before 2.12.10 and 2.13.x before 2.13.6 has a use-after-free in xmlSchemaIDCFillNodeTables and xmlSchemaBubbleIDCNodeTables in xmlschemas.c. To exploit this, a crafted XML document must be validated against an XML schema with certain identity constraints, or a crafted XML schema must be used.(CVE-2024-56171)libxml2 before 2.12.10 and 2.13.x before 2.13.6 has a stack-based buffer overflow in xmlSnprintfElements in valid.c. To exploit this, DTD validation must occur for an untrusted document or untrusted DTD. NOTE: this is similar to CVE-2017-9047.(CVE-2025-24928)libxml2 before 2.12.10 and 2.13.x before 2.13.6 has a NULL pointer dereference in xmlPatMatch in pattern.c.(CVE-2025-27113)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libxml2" release="15.oe2203sp4" version="2.9.14">
                         <filename>libxml2-2.9.14-15.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libxml2-debuginfo" release="15.oe2203sp4" version="2.9.14">
                         <filename>libxml2-debuginfo-2.9.14-15.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libxml2-debugsource" release="15.oe2203sp4" version="2.9.14">
                         <filename>libxml2-debugsource-2.9.14-15.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libxml2-devel" release="15.oe2203sp4" version="2.9.14">
                         <filename>libxml2-devel-2.9.14-15.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-libxml2" release="15.oe2203sp4" version="2.9.14">
                         <filename>python3-libxml2-2.9.14-15.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="libxml2-help" release="15.oe2203sp4" version="2.9.14">
                         <filename>libxml2-help-2.9.14-15.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libxml2" release="15.oe2203sp4" version="2.9.14">
                         <filename>libxml2-2.9.14-15.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libxml2-debuginfo" release="15.oe2203sp4" version="2.9.14">
                         <filename>libxml2-debuginfo-2.9.14-15.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libxml2-debugsource" release="15.oe2203sp4" version="2.9.14">
                         <filename>libxml2-debugsource-2.9.14-15.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libxml2-devel" release="15.oe2203sp4" version="2.9.14">
                         <filename>libxml2-devel-2.9.14-15.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-libxml2" release="15.oe2203sp4" version="2.9.14">
                         <filename>python3-libxml2-2.9.14-15.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1226</id>
          <title>An update for tomcat is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2025-02-28"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56337" id="CVE-2024-56337" title="CVE-2024-56337" type="cve"></reference>
          </references>
          <description>Time-of-check Time-of-use (TOCTOU) Race Condition vulnerability in Apache Tomcat.This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.1, from 10.1.0-M1 through 10.1.33, from 9.0.0.M1 through 9.0.97.The mitigation for CVE-2024-50379 was incomplete.Users running Tomcat on a case insensitive file system with the default servlet write enabled (readonly initialisation parameter set to the non-default value of false) may need additional configuration to fully mitigate CVE-2024-50379 depending on which version of Java they are using with Tomcat:- running on Java 8 or Java 11: the system property sun.io.useCanonCaches must be explicitly set to false (it defaults to true)- running on Java 17: the system property sun.io.useCanonCaches, if set, must be set to false (it defaults to false)- running on Java 21 onwards: no further configuration is required (the system property and the problematic cache have been removed)Tomcat 11.0.3, 10.1.35 and 9.0.99 onwards will include checks that sun.io.useCanonCaches is set appropriately before allowing the default servlet to be write enabled on a case insensitive file system. Tomcat will also set sun.io.useCanonCaches to false by default where it can.(CVE-2024-56337)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="noarch" name="tomcat" release="1.oe2203sp4" version="9.0.100">
                         <filename>tomcat-9.0.100-1.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="tomcat-help" release="1.oe2203sp4" version="9.0.100">
                         <filename>tomcat-help-9.0.100-1.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="tomcat-jsvc" release="1.oe2203sp4" version="9.0.100">
                         <filename>tomcat-jsvc-9.0.100-1.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1228</id>
          <title>An update for libpq is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-02-28"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1094" id="CVE-2025-1094" title="CVE-2025-1094" type="cve"></reference>
          </references>
          <description>Improper neutralization of quoting syntax in PostgreSQL libpq functions PQescapeLiteral(), PQescapeIdentifier(), PQescapeString(), and PQescapeStringConn() allows a database input provider to achieve SQL injection in certain usage patterns.  Specifically, SQL injection requires the application to use the function result to construct input to psql, the PostgreSQL interactive terminal.  Similarly, improper neutralization of quoting syntax in PostgreSQL command line utility programs allows a source of command line arguments to achieve SQL injection when client_encoding is BIG5 and server_encoding is one of EUC_TW or MULE_INTERNAL.  Versions before PostgreSQL 17.3, 16.7, 15.11, 14.16, and 13.19 are affected.(CVE-2025-1094)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libpq" release="1.oe2203sp4" version="13.20">
                         <filename>libpq-13.20-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libpq-debuginfo" release="1.oe2203sp4" version="13.20">
                         <filename>libpq-debuginfo-13.20-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libpq-debugsource" release="1.oe2203sp4" version="13.20">
                         <filename>libpq-debugsource-13.20-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libpq-devel" release="1.oe2203sp4" version="13.20">
                         <filename>libpq-devel-13.20-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libpq" release="1.oe2203sp4" version="13.20">
                         <filename>libpq-13.20-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libpq-debuginfo" release="1.oe2203sp4" version="13.20">
                         <filename>libpq-debuginfo-13.20-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libpq-debugsource" release="1.oe2203sp4" version="13.20">
                         <filename>libpq-debugsource-13.20-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libpq-devel" release="1.oe2203sp4" version="13.20">
                         <filename>libpq-devel-13.20-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1231</id>
          <title>An update for vim is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-02-28"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1215" id="CVE-2025-1215" title="CVE-2025-1215" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-26603" id="CVE-2025-26603" title="CVE-2025-26603" type="cve"></reference>
          </references>
          <description>A vulnerability classified as problematic was found in vim up to 9.1.1096. This vulnerability affects unknown code of the file src/main.c. The manipulation of the argument --log leads to memory corruption. It is possible to launch the attack on the local host. Upgrading to version 9.1.1097 is able to address this issue. The patch is identified as c5654b84480822817bb7b69ebc97c174c91185e9. It is recommended to upgrade the affected component.(CVE-2025-1215)Vim is a greatly improved version of the good old UNIX editor Vi. Vim allows to redirect screen messages using the `:redir` ex command to register, variables and files. It also allows to show the contents of registers using the `:registers` or `:display` ex command. When redirecting the output of `:display` to a register, Vim will free the register content before storing the new content in the register. Now when redirecting the `:display` command to a register that is being displayed, Vim will free the content while shortly afterwards trying to access it, which leads to a use-after-free. Vim pre 9.1.1115 checks in the ex_display() function, that it does not try to redirect to a register while displaying this register at the same time. However this check is not complete, and so Vim does not check the `+` and `*` registers (which typically donate the X11/clipboard registers, and when a clipboard connection is not possible will fall back to use register 0 instead. In Patch 9.1.1115 Vim will therefore skip outputting to register zero when trying to redirect to the clipboard registers `*` or `+`. Users are advised to upgrade. There are no known workarounds for this vulnerability.(CVE-2025-26603)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="2" arch="aarch64" name="vim-X11" release="32.oe2203sp4" version="9.0">
                         <filename>vim-X11-9.0-32.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-common" release="32.oe2203sp4" version="9.0">
                         <filename>vim-common-9.0-32.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-debuginfo" release="32.oe2203sp4" version="9.0">
                         <filename>vim-debuginfo-9.0-32.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-debugsource" release="32.oe2203sp4" version="9.0">
                         <filename>vim-debugsource-9.0-32.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-enhanced" release="32.oe2203sp4" version="9.0">
                         <filename>vim-enhanced-9.0-32.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-minimal" release="32.oe2203sp4" version="9.0">
                         <filename>vim-minimal-9.0-32.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="noarch" name="vim-filesystem" release="32.oe2203sp4" version="9.0">
                         <filename>vim-filesystem-9.0-32.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-X11" release="32.oe2203sp4" version="9.0">
                         <filename>vim-X11-9.0-32.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-common" release="32.oe2203sp4" version="9.0">
                         <filename>vim-common-9.0-32.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-debuginfo" release="32.oe2203sp4" version="9.0">
                         <filename>vim-debuginfo-9.0-32.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-debugsource" release="32.oe2203sp4" version="9.0">
                         <filename>vim-debugsource-9.0-32.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-enhanced" release="32.oe2203sp4" version="9.0">
                         <filename>vim-enhanced-9.0-32.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-minimal" release="32.oe2203sp4" version="9.0">
                         <filename>vim-minimal-9.0-32.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1233</id>
          <title>An update for grub2 is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-03-07"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45774" id="CVE-2024-45774" title="CVE-2024-45774" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45778" id="CVE-2024-45778" title="CVE-2024-45778" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45779" id="CVE-2024-45779" title="CVE-2024-45779" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45780" id="CVE-2024-45780" title="CVE-2024-45780" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56737" id="CVE-2024-56737" title="CVE-2024-56737" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-0622" id="CVE-2025-0622" title="CVE-2025-0622" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-0624" id="CVE-2025-0624" title="CVE-2025-0624" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-0677" id="CVE-2025-0677" title="CVE-2025-0677" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1125" id="CVE-2025-1125" title="CVE-2025-1125" type="cve"></reference>
          </references>
          <description>A flaw was found in grub2. A specially crafted JPEG file can cause the JPEG parser of grub2 to incorrectly check the bounds of its internal buffers, resulting in an out-of-bounds write. The possibility of overwriting sensitive information to bypass secure boot protections is not discarded.(CVE-2024-45774)A stack overflow flaw was found when reading a BFS file system. A crafted BFS filesystem may lead to an uncontrolled loop, causing grub2 to crash.(CVE-2024-45778)An integer overflow flaw was found in the BFS file system driver in grub2. When reading a file with an indirect extent map, grub2 fails to validate the number of extent entries to be read. A crafted or corrupted BFS filesystem may cause an integer overflow during the file reading, leading to a heap of bounds read. As a consequence, sensitive data may be leaked, or grub2 will crash.(CVE-2024-45779)A flaw was found in grub2. When reading tar files, grub2 allocates an internal buffer for the file name. However, it fails to properly verify the allocation against possible integer overflows. It&#39;s possible to cause the allocation length to overflow with a crafted tar file, leading to a heap out-of-bounds write. This flaw eventually allows an attacker to circumvent secure boot protections.(CVE-2024-45780)GNU GRUB (aka GRUB2) through 2.12 has a heap-based buffer overflow in fs/hfs.c via crafted sblock data in an HFS filesystem.(CVE-2024-56737)A flaw was found in command/gpg. In some scenarios, hooks created by loaded modules are not removed when the related module is unloaded. This flaw allows an attacker to force grub2 to call the hooks once the module that registered it was unloaded, leading to a use-after-free vulnerability. If correctly exploited, this vulnerability may result in arbitrary code execution, eventually allowing the attacker to bypass secure boot protections.(CVE-2025-0622)A flaw was found in grub2. During the network boot process, when trying to search for the configuration file, grub copies data from a user controlled environment variable into an internal buffer using the grub_strcpy() function. During this step, it fails to consider the environment variable length when allocating the internal buffer, resulting in an out-of-bounds write. If correctly exploited, this issue may result in remote code execution through the same network segment grub is searching for the boot information, which can be used to by-pass secure boot protections.(CVE-2025-0624)A flaw was found in grub2. When performing a symlink lookup, the grub&#39;s UFS module checks the inode&#39;s data size to allocate the internal buffer to read the file content, however, it fails to check if the symlink data size has overflown. When this occurs, grub_malloc() may be called with a smaller value than needed. When further reading the data from the disk into the buffer, the grub_ufs_lookup_symlink() function will write past the end of the allocated size. An attack can leverage this by crafting a malicious filesystem, and as a result, it will corrupt data stored in the heap, allowing for arbitrary code execution used to by-pass secure boot mechanisms.(CVE-2025-0677)When reading data from a hfs filesystem, grub&#39;s hfs filesystem module uses user-controlled parameters from the filesystem metadata to calculate the internal buffers size, however it misses to properly check for integer overflows. A maliciouly crafted filesystem may lead some of those buffer size calculation to overflow, causing it to perform a grub_malloc() operation with a smaller size than expected. As a result the hfsplus_open_compressed_real() function will write past of the internal buffer length. This flaw may be leveraged to corrupt grub&#39;s internal critical data and may result in arbitrary code execution by-passing secure boot protections.(CVE-2025-1125)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="grub2-debuginfo" release="51.oe2203sp4" version="2.06">
                         <filename>grub2-debuginfo-2.06-51.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="grub2-debugsource" release="51.oe2203sp4" version="2.06">
                         <filename>grub2-debugsource-2.06-51.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="grub2-efi-aa64" release="51.oe2203sp4" version="2.06">
                         <filename>grub2-efi-aa64-2.06-51.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="grub2-efi-aa64-cdboot" release="51.oe2203sp4" version="2.06">
                         <filename>grub2-efi-aa64-cdboot-2.06-51.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="grub2-tools" release="51.oe2203sp4" version="2.06">
                         <filename>grub2-tools-2.06-51.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="grub2-tools-extra" release="51.oe2203sp4" version="2.06">
                         <filename>grub2-tools-extra-2.06-51.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="grub2-tools-minimal" release="51.oe2203sp4" version="2.06">
                         <filename>grub2-tools-minimal-2.06-51.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="grub2-common" release="51.oe2203sp4" version="2.06">
                         <filename>grub2-common-2.06-51.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="grub2-efi-aa64-modules" release="51.oe2203sp4" version="2.06">
                         <filename>grub2-efi-aa64-modules-2.06-51.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="grub2-efi-ia32-modules" release="51.oe2203sp4" version="2.06">
                         <filename>grub2-efi-ia32-modules-2.06-51.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="grub2-efi-x64-modules" release="51.oe2203sp4" version="2.06">
                         <filename>grub2-efi-x64-modules-2.06-51.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="grub2-help" release="51.oe2203sp4" version="2.06">
                         <filename>grub2-help-2.06-51.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="grub2-pc-modules" release="51.oe2203sp4" version="2.06">
                         <filename>grub2-pc-modules-2.06-51.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-debuginfo" release="51.oe2203sp4" version="2.06">
                         <filename>grub2-debuginfo-2.06-51.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-debugsource" release="51.oe2203sp4" version="2.06">
                         <filename>grub2-debugsource-2.06-51.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-efi-ia32" release="51.oe2203sp4" version="2.06">
                         <filename>grub2-efi-ia32-2.06-51.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-efi-ia32-cdboot" release="51.oe2203sp4" version="2.06">
                         <filename>grub2-efi-ia32-cdboot-2.06-51.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-efi-x64" release="51.oe2203sp4" version="2.06">
                         <filename>grub2-efi-x64-2.06-51.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-efi-x64-cdboot" release="51.oe2203sp4" version="2.06">
                         <filename>grub2-efi-x64-cdboot-2.06-51.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-pc" release="51.oe2203sp4" version="2.06">
                         <filename>grub2-pc-2.06-51.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-tools" release="51.oe2203sp4" version="2.06">
                         <filename>grub2-tools-2.06-51.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-tools-efi" release="51.oe2203sp4" version="2.06">
                         <filename>grub2-tools-efi-2.06-51.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-tools-extra" release="51.oe2203sp4" version="2.06">
                         <filename>grub2-tools-extra-2.06-51.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-tools-minimal" release="51.oe2203sp4" version="2.06">
                         <filename>grub2-tools-minimal-2.06-51.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1236</id>
          <title>An update for rust is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-03-07"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-46176" id="CVE-2022-46176" title="CVE-2022-46176" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38497" id="CVE-2023-38497" title="CVE-2023-38497" type="cve"></reference>
          </references>
          <description>Cargo is a Rust package manager. The Rust Security Response WG was notified that Cargo did not perform SSH host key verification when cloning indexes and dependencies via SSH. An attacker could exploit this to perform man-in-the-middle (MITM) attacks. This vulnerability has been assigned CVE-2022-46176. All Rust versions containing Cargo before 1.66.1 are vulnerable. Note that even if you don&#39;t explicitly use SSH for alternate registry indexes or crate dependencies, you might be affected by this vulnerability if you have configured git to replace HTTPS connections to GitHub with SSH (through git&#39;s [`url.&lt;base&gt;.insteadOf`][1] setting), as that&#39;d cause you to clone the crates.io index through SSH. Rust 1.66.1 will ensure Cargo checks the SSH host key and abort the connection if the server&#39;s public key is not already trusted. We recommend everyone to upgrade as soon as possible. (CVE-2022-46176)Cargo downloads the Rust project’s dependencies and compiles the project. Cargo prior to version 0.72.2, bundled with Rust prior to version 1.71.1, did not respect the umask when extracting crate archives on UNIX-like systems. If the user downloaded a crate containing files writeable by any local user, another local user could exploit this to change the source code compiled and executed by the current user. To prevent existing cached extractions from being exploitable, the Cargo binary version 0.72.2 included in Rust 1.71.1 or later will purge caches generated by older Cargo versions automatically. As a workaround, configure one&#39;s system to prevent other local users from accessing the Cargo directory, usually located in `~/.cargo`.(CVE-2023-38497)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="cargo" release="1.oe2203sp4" version="1.76.0">
                         <filename>cargo-1.76.0-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="clippy" release="1.oe2203sp4" version="1.76.0">
                         <filename>clippy-1.76.0-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rust" release="1.oe2203sp4" version="1.76.0">
                         <filename>rust-1.76.0-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rust-analyzer" release="1.oe2203sp4" version="1.76.0">
                         <filename>rust-analyzer-1.76.0-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rust-debuginfo" release="1.oe2203sp4" version="1.76.0">
                         <filename>rust-debuginfo-1.76.0-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rust-debugsource" release="1.oe2203sp4" version="1.76.0">
                         <filename>rust-debugsource-1.76.0-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rust-help" release="1.oe2203sp4" version="1.76.0">
                         <filename>rust-help-1.76.0-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rust-std-static" release="1.oe2203sp4" version="1.76.0">
                         <filename>rust-std-static-1.76.0-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rustfmt" release="1.oe2203sp4" version="1.76.0">
                         <filename>rustfmt-1.76.0-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="rust-debugger-common" release="1.oe2203sp4" version="1.76.0">
                         <filename>rust-debugger-common-1.76.0-1.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rust-gdb" release="1.oe2203sp4" version="1.76.0">
                         <filename>rust-gdb-1.76.0-1.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rust-lldb" release="1.oe2203sp4" version="1.76.0">
                         <filename>rust-lldb-1.76.0-1.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rust-src" release="1.oe2203sp4" version="1.76.0">
                         <filename>rust-src-1.76.0-1.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cargo" release="1.oe2203sp4" version="1.76.0">
                         <filename>cargo-1.76.0-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="clippy" release="1.oe2203sp4" version="1.76.0">
                         <filename>clippy-1.76.0-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rust" release="1.oe2203sp4" version="1.76.0">
                         <filename>rust-1.76.0-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rust-analyzer" release="1.oe2203sp4" version="1.76.0">
                         <filename>rust-analyzer-1.76.0-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rust-debuginfo" release="1.oe2203sp4" version="1.76.0">
                         <filename>rust-debuginfo-1.76.0-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rust-debugsource" release="1.oe2203sp4" version="1.76.0">
                         <filename>rust-debugsource-1.76.0-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rust-help" release="1.oe2203sp4" version="1.76.0">
                         <filename>rust-help-1.76.0-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rust-std-static" release="1.oe2203sp4" version="1.76.0">
                         <filename>rust-std-static-1.76.0-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rustfmt" release="1.oe2203sp4" version="1.76.0">
                         <filename>rustfmt-1.76.0-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1242</id>
          <title>An update for glibc is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-03-07"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-0395" id="CVE-2025-0395" title="CVE-2025-0395" type="cve"></reference>
          </references>
          <description>When the assert() function in the GNU C Library versions 2.13 to 2.40 fails, it does not allocate enough space for the assertion failure message string and size information, which may lead to a buffer overflow if the message string size aligns to page size.(CVE-2025-0395)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="glibc" release="166.oe2203sp4" version="2.34">
                         <filename>glibc-2.34-166.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-all-langpacks" release="166.oe2203sp4" version="2.34">
                         <filename>glibc-all-langpacks-2.34-166.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-common" release="166.oe2203sp4" version="2.34">
                         <filename>glibc-common-2.34-166.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-compat-2.17" release="166.oe2203sp4" version="2.34">
                         <filename>glibc-compat-2.17-2.34-166.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-debuginfo" release="166.oe2203sp4" version="2.34">
                         <filename>glibc-debuginfo-2.34-166.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-debugsource" release="166.oe2203sp4" version="2.34">
                         <filename>glibc-debugsource-2.34-166.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-debugutils" release="166.oe2203sp4" version="2.34">
                         <filename>glibc-debugutils-2.34-166.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-devel" release="166.oe2203sp4" version="2.34">
                         <filename>glibc-devel-2.34-166.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-locale-archive" release="166.oe2203sp4" version="2.34">
                         <filename>glibc-locale-archive-2.34-166.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-locale-source" release="166.oe2203sp4" version="2.34">
                         <filename>glibc-locale-source-2.34-166.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-nss-devel" release="166.oe2203sp4" version="2.34">
                         <filename>glibc-nss-devel-2.34-166.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libnsl" release="166.oe2203sp4" version="2.34">
                         <filename>libnsl-2.34-166.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="nscd" release="166.oe2203sp4" version="2.34">
                         <filename>nscd-2.34-166.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="nss_modules" release="166.oe2203sp4" version="2.34">
                         <filename>nss_modules-2.34-166.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="glibc-help" release="166.oe2203sp4" version="2.34">
                         <filename>glibc-help-2.34-166.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc" release="166.oe2203sp4" version="2.34">
                         <filename>glibc-2.34-166.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-all-langpacks" release="166.oe2203sp4" version="2.34">
                         <filename>glibc-all-langpacks-2.34-166.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-common" release="166.oe2203sp4" version="2.34">
                         <filename>glibc-common-2.34-166.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-compat-2.17" release="166.oe2203sp4" version="2.34">
                         <filename>glibc-compat-2.17-2.34-166.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-debuginfo" release="166.oe2203sp4" version="2.34">
                         <filename>glibc-debuginfo-2.34-166.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-debugsource" release="166.oe2203sp4" version="2.34">
                         <filename>glibc-debugsource-2.34-166.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-debugutils" release="166.oe2203sp4" version="2.34">
                         <filename>glibc-debugutils-2.34-166.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-devel" release="166.oe2203sp4" version="2.34">
                         <filename>glibc-devel-2.34-166.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-locale-archive" release="166.oe2203sp4" version="2.34">
                         <filename>glibc-locale-archive-2.34-166.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-locale-source" release="166.oe2203sp4" version="2.34">
                         <filename>glibc-locale-source-2.34-166.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-nss-devel" release="166.oe2203sp4" version="2.34">
                         <filename>glibc-nss-devel-2.34-166.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libnsl" release="166.oe2203sp4" version="2.34">
                         <filename>libnsl-2.34-166.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="nscd" release="166.oe2203sp4" version="2.34">
                         <filename>nscd-2.34-166.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="nss_modules" release="166.oe2203sp4" version="2.34">
                         <filename>nss_modules-2.34-166.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1243</id>
          <title>An update for libcap is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-03-07"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1390" id="CVE-2025-1390" title="CVE-2025-1390" type="cve"></reference>
          </references>
          <description>The PAM module pam_cap.so of libcap configuration supports group names starting with “@”, during actual parsing, configurations not starting with “@” are incorrectly recognized as group names. This may result in nonintended users being granted an inherited capability set, potentially leading to security risks. Attackers can exploit this vulnerability to achieve local privilege escalation on systems where /etc/security/capability.conf is used to configure user inherited privileges by constructing specific usernames.(CVE-2025-1390)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libcap" release="8.oe2203sp4" version="2.61">
                         <filename>libcap-2.61-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libcap-debuginfo" release="8.oe2203sp4" version="2.61">
                         <filename>libcap-debuginfo-2.61-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libcap-debugsource" release="8.oe2203sp4" version="2.61">
                         <filename>libcap-debugsource-2.61-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libcap-devel" release="8.oe2203sp4" version="2.61">
                         <filename>libcap-devel-2.61-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="libcap-help" release="8.oe2203sp4" version="2.61">
                         <filename>libcap-help-2.61-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libcap" release="8.oe2203sp4" version="2.61">
                         <filename>libcap-2.61-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libcap-debuginfo" release="8.oe2203sp4" version="2.61">
                         <filename>libcap-debuginfo-2.61-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libcap-debugsource" release="8.oe2203sp4" version="2.61">
                         <filename>libcap-debugsource-2.61-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libcap-devel" release="8.oe2203sp4" version="2.61">
                         <filename>libcap-devel-2.61-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1247</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-03-07"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56606" id="CVE-2024-56606" title="CVE-2024-56606" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57908" id="CVE-2024-57908" title="CVE-2024-57908" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57912" id="CVE-2024-57912" title="CVE-2024-57912" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57977" id="CVE-2024-57977" title="CVE-2024-57977" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21650" id="CVE-2025-21650" title="CVE-2025-21650" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21651" id="CVE-2025-21651" title="CVE-2025-21651" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21731" id="CVE-2025-21731" title="CVE-2025-21731" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21815" id="CVE-2025-21815" title="CVE-2025-21815" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:af_packet: avoid erroring out after sock_init_data() in packet_create()After sock_init_data() the allocated sk object is attached to the providedsock object. On error, packet_create() frees the sk object leaving thedangling pointer in the sock object on return. Some other code may tryto use this pointer and cause use-after-free.(CVE-2024-56606)In the Linux kernel, the following vulnerability has been resolved:iio: imu: kmx61: fix information leak in triggered bufferThe &#39;buffer&#39; local array is used to push data to user space from atriggered buffer, but it does not set values for inactive channels, asit only uses iio_for_each_active_channel() to assign new values.Initialize the array to zero before using it to avoid pushinguninitialized information to userspace.(CVE-2024-57908)In the Linux kernel, the following vulnerability has been resolved:iio: pressure: zpa2326: fix information leak in triggered bufferThe &#39;sample&#39; local struct is used to push data to user space from atriggered buffer, but it has a hole between the temperature and thetimestamp (u32 pressure, u16 temperature, GAP, u64 timestamp).This hole is never initialized.Initialize the struct to zero before using it to avoid pushinguninitialized information to userspace.(CVE-2024-57912)In the Linux kernel, the following vulnerability has been resolved:memcg: fix soft lockup in the OOM processA soft lockup issue was found in the product with about 56,000 tasks werein the OOM cgroup, it was traversing them when the soft lockup wastriggered.watchdog: BUG: soft lockup - CPU#2 stuck for 23s! [VM Thread:1503066]CPU: 2 PID: 1503066 Comm: VM Thread Kdump: loaded Tainted: GHardware name: Huawei Cloud OpenStack Nova, BIOSRIP: 0010:console_unlock+0x343/0x540RSP: 0000:ffffb751447db9a0 EFLAGS: 00000247 ORIG_RAX: ffffffffffffff13RAX: 0000000000000001 RBX: 0000000000000000 RCX: 00000000ffffffffRDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000247RBP: ffffffffafc71f90 R08: 0000000000000000 R09: 0000000000000040R10: 0000000000000080 R11: 0000000000000000 R12: ffffffffafc74bd0R13: ffffffffaf60a220 R14: 0000000000000247 R15: 0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f2fe6ad91f0 CR3: 00000004b2076003 CR4: 0000000000360ee0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: vprintk_emit+0x193/0x280 printk+0x52/0x6e dump_task+0x114/0x130 mem_cgroup_scan_tasks+0x76/0x100 dump_header+0x1fe/0x210 oom_kill_process+0xd1/0x100 out_of_memory+0x125/0x570 mem_cgroup_out_of_memory+0xb5/0xd0 try_charge+0x720/0x770 mem_cgroup_try_charge+0x86/0x180 mem_cgroup_try_charge_delay+0x1c/0x40 do_anonymous_page+0xb5/0x390 handle_mm_fault+0xc4/0x1f0This is because thousands of processes are in the OOM cgroup, it takes along time to traverse all of them.  As a result, this lead to soft lockupin the OOM process.To fix this issue, call &#39;cond_resched&#39; in the &#39;mem_cgroup_scan_tasks&#39;function per 1000 iterations.  For global OOM, call&#39;touch_softlockup_watchdog&#39; per 1000 iterations to avoid this issue.(CVE-2024-57977)In the Linux kernel, the following vulnerability has been resolved:net: hns3: fixed hclge_fetch_pf_reg accesses bar space out of bounds issueThe TQP BAR space is divided into two segments. TQPs 0-1023 and TQPs1024-1279 are in different BAR space addresses. However,hclge_fetch_pf_reg does not distinguish the tqp space information whenreading the tqp space information. When the number of TQPs is greaterthan 1024, access bar space overwriting occurs.The problem of different segments has been considered during theinitialization of tqp.io_base. Therefore, tqp.io_base is directly usedwhen the queue is read in hclge_fetch_pf_reg.The error message:Unable to handle kernel paging request at virtual address ffff800037200000pc : hclge_fetch_pf_reg+0x138/0x250 [hclge]lr : hclge_get_regs+0x84/0x1d0 [hclge]Call trace: hclge_fetch_pf_reg+0x138/0x250 [hclge] hclge_get_regs+0x84/0x1d0 [hclge] hns3_get_regs+0x2c/0x50 [hns3] ethtool_get_regs+0xf4/0x270 dev_ethtool+0x674/0x8a0 dev_ioctl+0x270/0x36c sock_do_ioctl+0x110/0x2a0 sock_ioctl+0x2ac/0x530 __arm64_sys_ioctl+0xa8/0x100 invoke_syscall+0x4c/0x124 el0_svc_common.constprop.0+0x140/0x15c do_el0_svc+0x30/0xd0 el0_svc+0x1c/0x2c el0_sync_handler+0xb0/0xb4 el0_sync+0x168/0x180(CVE-2025-21650)In the Linux kernel, the following vulnerability has been resolved:net: hns3: don&#39;t auto enable misc vectorCurrently, there is a time window between misc irq enabledand service task inited. If an interrupte is reported atthis time, it will cause warning like below:[   16.324639] Call trace:[   16.324641]  __queue_delayed_work+0xb8/0xe0[   16.324643]  mod_delayed_work_on+0x78/0xd0[   16.324655]  hclge_errhand_task_schedule+0x58/0x90 [hclge][   16.324662]  hclge_misc_irq_handle+0x168/0x240 [hclge][   16.324666]  __handle_irq_event_percpu+0x64/0x1e0[   16.324667]  handle_irq_event+0x80/0x170[   16.324670]  handle_fasteoi_edge_irq+0x110/0x2bc[   16.324671]  __handle_domain_irq+0x84/0xfc[   16.324673]  gic_handle_irq+0x88/0x2c0[   16.324674]  el1_irq+0xb8/0x140[   16.324677]  arch_cpu_idle+0x18/0x40[   16.324679]  default_idle_call+0x5c/0x1bc[   16.324682]  cpuidle_idle_call+0x18c/0x1c4[   16.324684]  do_idle+0x174/0x17c[   16.324685]  cpu_startup_entry+0x30/0x6c[   16.324687]  secondary_start_kernel+0x1a4/0x280[   16.324688] ---[ end trace 6aa0bff672a964aa ]---So don&#39;t auto enable misc vector when request irq..(CVE-2025-21651)In the Linux kernel, the following vulnerability has been resolved:nbd: don&#39;t allow reconnect after disconnectFollowing process can cause nbd_config UAF:1) grab nbd_config temporarily;2) nbd_genl_disconnect() flush all recv_work() and release theinitial reference:  nbd_genl_disconnect   nbd_disconnect_and_put    nbd_disconnect     flush_workqueue(nbd-&gt;recv_workq)    if (test_and_clear_bit(NBD_RT_HAS_CONFIG_REF, ...))     nbd_config_put     -&gt; due to step 1), reference is still not zero3) nbd_genl_reconfigure() queue recv_work() again;  nbd_genl_reconfigure   config = nbd_get_config_unlocked(nbd)   if (!config)   -&gt; succeed   if (!test_bit(NBD_RT_BOUND, ...))   -&gt; succeed   nbd_reconnect_socket    queue_work(nbd-&gt;recv_workq, &amp;args-&gt;work)4) step 1) release the reference;5) Finially, recv_work() will trigger UAF:  recv_work   nbd_config_put(nbd)   -&gt; nbd_config is freed   atomic_dec(&amp;config-&gt;recv_threads)   -&gt; UAFFix the problem by clearing NBD_RT_BOUND in nbd_genl_disconnect(), sothat nbd_genl_reconfigure() will fail.(CVE-2025-21731)In the Linux kernel, the following vulnerability has been resolved:mm/compaction: fix UBSAN shift-out-of-bounds warningsyzkaller reported a UBSAN shift-out-of-bounds warning of (1UL &lt;&lt; order)in isolate_freepages_block().  The bogus compound_order can be any valuebecause it is union with flags.  Add back the MAX_PAGE_ORDER check to fixthe warning.(CVE-2025-21815)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="bpftool" release="252.0.0.156.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-252.0.0.156.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="252.0.0.156.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-252.0.0.156.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="252.0.0.156.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-252.0.0.156.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="252.0.0.156.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-252.0.0.156.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="252.0.0.156.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-252.0.0.156.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="252.0.0.156.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-252.0.0.156.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="252.0.0.156.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-252.0.0.156.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="252.0.0.156.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-252.0.0.156.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="252.0.0.156.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-252.0.0.156.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="252.0.0.156.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-252.0.0.156.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="252.0.0.156.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-252.0.0.156.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="252.0.0.156.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-252.0.0.156.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="252.0.0.156.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-252.0.0.156.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="252.0.0.156.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-252.0.0.156.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="252.0.0.156.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-252.0.0.156.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="252.0.0.156.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-252.0.0.156.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="252.0.0.156.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-252.0.0.156.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="252.0.0.156.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-252.0.0.156.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="252.0.0.156.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-252.0.0.156.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="252.0.0.156.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-252.0.0.156.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="252.0.0.156.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-252.0.0.156.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="252.0.0.156.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-252.0.0.156.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="252.0.0.156.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-252.0.0.156.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="252.0.0.156.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-252.0.0.156.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="252.0.0.156.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-252.0.0.156.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="252.0.0.156.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-252.0.0.156.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="252.0.0.156.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-252.0.0.156.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="252.0.0.156.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-252.0.0.156.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="252.0.0.156.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-252.0.0.156.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="252.0.0.156.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-252.0.0.156.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1253</id>
          <title>An update for musl is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-03-07"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-26519" id="CVE-2025-26519" title="CVE-2025-26519" type="cve"></reference>
          </references>
          <description>musl libc 0.9.13 through 1.2.5 before 1.2.6 has an out-of-bounds write vulnerability when an attacker can trigger iconv conversion of untrusted EUC-KR text to UTF-8.(CVE-2025-26519)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="musl-debuginfo" release="3.oe2203sp4" version="1.2.3">
                         <filename>musl-debuginfo-1.2.3-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="musl-debugsource" release="3.oe2203sp4" version="1.2.3">
                         <filename>musl-debugsource-1.2.3-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="musl-devel" release="3.oe2203sp4" version="1.2.3">
                         <filename>musl-devel-1.2.3-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="musl-gcc" release="3.oe2203sp4" version="1.2.3">
                         <filename>musl-gcc-1.2.3-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="musl-libc" release="3.oe2203sp4" version="1.2.3">
                         <filename>musl-libc-1.2.3-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="musl-libc-static" release="3.oe2203sp4" version="1.2.3">
                         <filename>musl-libc-static-1.2.3-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="musl-debuginfo" release="3.oe2203sp4" version="1.2.3">
                         <filename>musl-debuginfo-1.2.3-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="musl-debugsource" release="3.oe2203sp4" version="1.2.3">
                         <filename>musl-debugsource-1.2.3-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="musl-devel" release="3.oe2203sp4" version="1.2.3">
                         <filename>musl-devel-1.2.3-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="musl-gcc" release="3.oe2203sp4" version="1.2.3">
                         <filename>musl-gcc-1.2.3-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="musl-libc" release="3.oe2203sp4" version="1.2.3">
                         <filename>musl-libc-1.2.3-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="musl-libc-static" release="3.oe2203sp4" version="1.2.3">
                         <filename>musl-libc-static-1.2.3-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1256</id>
          <title>An update for libxkbfile is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-03-07"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-26595" id="CVE-2025-26595" title="CVE-2025-26595" type="cve"></reference>
          </references>
          <description>A buffer overflow flaw was found in X.Org and Xwayland. The code in XkbVModMaskText() allocates a fixed-sized buffer on the stack and copies the names of the virtual modifiers to that buffer. The code fails to check the bounds of the buffer and would copy the data regardless of the size.(CVE-2025-26595)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libxkbfile" release="6.oe2203sp4" version="1.1.0">
                         <filename>libxkbfile-1.1.0-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libxkbfile-debuginfo" release="6.oe2203sp4" version="1.1.0">
                         <filename>libxkbfile-debuginfo-1.1.0-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libxkbfile-debugsource" release="6.oe2203sp4" version="1.1.0">
                         <filename>libxkbfile-debugsource-1.1.0-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libxkbfile-devel" release="6.oe2203sp4" version="1.1.0">
                         <filename>libxkbfile-devel-1.1.0-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libxkbfile" release="6.oe2203sp4" version="1.1.0">
                         <filename>libxkbfile-1.1.0-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libxkbfile-debuginfo" release="6.oe2203sp4" version="1.1.0">
                         <filename>libxkbfile-debuginfo-1.1.0-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libxkbfile-debugsource" release="6.oe2203sp4" version="1.1.0">
                         <filename>libxkbfile-debugsource-1.1.0-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libxkbfile-devel" release="6.oe2203sp4" version="1.1.0">
                         <filename>libxkbfile-devel-1.1.0-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1257</id>
          <title>An update for undertow is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2025-03-07"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2017-12196" id="CVE-2017-12196" title="CVE-2017-12196" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2019-10184" id="CVE-2019-10184" title="CVE-2019-10184" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2019-10212" id="CVE-2019-10212" title="CVE-2019-10212" type="cve"></reference>
          </references>
          <description>undertow before versions 1.4.18.SP1, 2.0.2.Final, 1.4.24.Final was found vulnerable when using Digest authentication, the server does not ensure that the value of URI in the Authorization header matches the URI in HTTP request line. This allows the attacker to cause a MITM attack and access the desired content on the server.(CVE-2017-12196)undertow before version 2.0.23.Final is vulnerable to an information leak issue. Web apps may have their directory structures predicted through requests without trailing slashes via the api.(CVE-2019-10184)A flaw was found in, all under 2.0.20, in the Undertow DEBUG log for io.undertow.request.security. If enabled, an attacker could abuse this flaw to obtain the user&#39;s credentials from the log files.(CVE-2019-10212)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="noarch" name="undertow" release="9.oe2203sp4" version="1.4.0">
                         <filename>undertow-1.4.0-9.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="undertow-javadoc" release="9.oe2203sp4" version="1.4.0">
                         <filename>undertow-javadoc-1.4.0-9.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1260</id>
          <title>An update for python-django is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-03-14"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-26699" id="CVE-2025-26699" title="CVE-2025-26699" type="cve"></reference>
          </references>
          <description>An issue was discovered in Django 5.1 before 5.1.7, 5.0 before 5.0.13, and 4.2 before 4.2.20. The django.utils.text.wrap() method and wordwrap template filter are subject to a potential denial-of-service attack when used with very long strings.(CVE-2025-26699)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="python-django-help" release="5.oe2203sp4" version="4.2.15">
                         <filename>python-django-help-4.2.15-5.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-Django" release="5.oe2203sp4" version="4.2.15">
                         <filename>python3-Django-4.2.15-5.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1261</id>
          <title>An update for ruby is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-03-14"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-27219" id="CVE-2025-27219" title="CVE-2025-27219" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-27220" id="CVE-2025-27220" title="CVE-2025-27220" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-27221" id="CVE-2025-27221" title="CVE-2025-27221" type="cve"></reference>
          </references>
          <description>In the CGI gem before 0.4.2 for Ruby, the CGI::Cookie.parse method in the CGI library contains a potential Denial of Service (DoS) vulnerability. The method does not impose any limit on the length of the raw cookie value it processes. This oversight can lead to excessive resource consumption when parsing extremely large cookies.(CVE-2025-27219)In the CGI gem before 0.4.2 for Ruby, a Regular Expression Denial of Service (ReDoS) vulnerability exists in the Util#escapeElement method.(CVE-2025-27220)In the URI gem before 1.0.3 for Ruby, the URI handling methods (URI.join, URI#merge, URI#+) have an inadvertent leakage of authentication credentials because userinfo is retained even after changing the host.(CVE-2025-27221)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="ruby" release="142.oe2203sp4" version="3.0.3">
                         <filename>ruby-3.0.3-142.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ruby-debuginfo" release="142.oe2203sp4" version="3.0.3">
                         <filename>ruby-debuginfo-3.0.3-142.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ruby-debugsource" release="142.oe2203sp4" version="3.0.3">
                         <filename>ruby-debugsource-3.0.3-142.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ruby-devel" release="142.oe2203sp4" version="3.0.3">
                         <filename>ruby-devel-3.0.3-142.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-bigdecimal" release="142.oe2203sp4" version="3.0.0">
                         <filename>rubygem-bigdecimal-3.0.0-142.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-io-console" release="142.oe2203sp4" version="0.5.7">
                         <filename>rubygem-io-console-0.5.7-142.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-json" release="142.oe2203sp4" version="2.5.1">
                         <filename>rubygem-json-2.5.1-142.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-openssl" release="142.oe2203sp4" version="2.2.1">
                         <filename>rubygem-openssl-2.2.1-142.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-psych" release="142.oe2203sp4" version="3.3.2">
                         <filename>rubygem-psych-3.3.2-142.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="ruby-help" release="142.oe2203sp4" version="3.0.3">
                         <filename>ruby-help-3.0.3-142.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="ruby-irb" release="142.oe2203sp4" version="3.0.3">
                         <filename>ruby-irb-3.0.3-142.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-bundler" release="142.oe2203sp4" version="2.2.32">
                         <filename>rubygem-bundler-2.2.32-142.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-did_you_mean" release="142.oe2203sp4" version="1.5.0">
                         <filename>rubygem-did_you_mean-1.5.0-142.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-minitest" release="142.oe2203sp4" version="5.14.2">
                         <filename>rubygem-minitest-5.14.2-142.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rake" release="142.oe2203sp4" version="13.0.3">
                         <filename>rubygem-rake-13.0.3-142.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rbs" release="142.oe2203sp4" version="1.4.0">
                         <filename>rubygem-rbs-1.4.0-142.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rdoc" release="142.oe2203sp4" version="6.3.3">
                         <filename>rubygem-rdoc-6.3.3-142.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rexml" release="142.oe2203sp4" version="3.2.5">
                         <filename>rubygem-rexml-3.2.5-142.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rss" release="142.oe2203sp4" version="0.2.9">
                         <filename>rubygem-rss-0.2.9-142.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-test-unit" release="142.oe2203sp4" version="3.3.7">
                         <filename>rubygem-test-unit-3.3.7-142.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-typeprof" release="142.oe2203sp4" version="0.15.2">
                         <filename>rubygem-typeprof-0.15.2-142.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygems" release="142.oe2203sp4" version="3.2.32">
                         <filename>rubygems-3.2.32-142.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygems-devel" release="142.oe2203sp4" version="3.2.32">
                         <filename>rubygems-devel-3.2.32-142.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby" release="142.oe2203sp4" version="3.0.3">
                         <filename>ruby-3.0.3-142.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby-debuginfo" release="142.oe2203sp4" version="3.0.3">
                         <filename>ruby-debuginfo-3.0.3-142.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby-debugsource" release="142.oe2203sp4" version="3.0.3">
                         <filename>ruby-debugsource-3.0.3-142.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby-devel" release="142.oe2203sp4" version="3.0.3">
                         <filename>ruby-devel-3.0.3-142.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-bigdecimal" release="142.oe2203sp4" version="3.0.0">
                         <filename>rubygem-bigdecimal-3.0.0-142.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-io-console" release="142.oe2203sp4" version="0.5.7">
                         <filename>rubygem-io-console-0.5.7-142.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-json" release="142.oe2203sp4" version="2.5.1">
                         <filename>rubygem-json-2.5.1-142.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-openssl" release="142.oe2203sp4" version="2.2.1">
                         <filename>rubygem-openssl-2.2.1-142.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-psych" release="142.oe2203sp4" version="3.3.2">
                         <filename>rubygem-psych-3.3.2-142.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1265</id>
          <title>An update for firefox is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2025-03-14"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-36315" id="CVE-2022-36315" title="CVE-2022-36315" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-36316" id="CVE-2022-36316" title="CVE-2022-36316" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38475" id="CVE-2022-38475" title="CVE-2022-38475" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45417" id="CVE-2022-45417" title="CVE-2022-45417" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45419" id="CVE-2022-45419" title="CVE-2022-45419" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-46879" id="CVE-2022-46879" title="CVE-2022-46879" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-46883" id="CVE-2022-46883" title="CVE-2022-46883" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25731" id="CVE-2023-25731" title="CVE-2023-25731" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25733" id="CVE-2023-25733" title="CVE-2023-25733" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25736" id="CVE-2023-25736" title="CVE-2023-25736" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25750" id="CVE-2023-25750" title="CVE-2023-25750" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28160" id="CVE-2023-28160" title="CVE-2023-28160" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28177" id="CVE-2023-28177" title="CVE-2023-28177" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29537" id="CVE-2023-29537" title="CVE-2023-29537" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29538" id="CVE-2023-29538" title="CVE-2023-29538" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29540" id="CVE-2023-29540" title="CVE-2023-29540" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29547" id="CVE-2023-29547" title="CVE-2023-29547" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29549" id="CVE-2023-29549" title="CVE-2023-29549" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32208" id="CVE-2023-32208" title="CVE-2023-32208" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32209" id="CVE-2023-32209" title="CVE-2023-32209" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32210" id="CVE-2023-32210" title="CVE-2023-32210" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34415" id="CVE-2023-34415" title="CVE-2023-34415" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34417" id="CVE-2023-34417" title="CVE-2023-34417" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3482" id="CVE-2023-3482" title="CVE-2023-3482" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3600" id="CVE-2023-3600" title="CVE-2023-3600" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37203" id="CVE-2023-37203" title="CVE-2023-37203" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37204" id="CVE-2023-37204" title="CVE-2023-37204" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37205" id="CVE-2023-37205" title="CVE-2023-37205" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37206" id="CVE-2023-37206" title="CVE-2023-37206" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37209" id="CVE-2023-37209" title="CVE-2023-37209" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37210" id="CVE-2023-37210" title="CVE-2023-37210" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37212" id="CVE-2023-37212" title="CVE-2023-37212" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4051" id="CVE-2023-4051" title="CVE-2023-4051" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4053" id="CVE-2023-4053" title="CVE-2023-4053" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4058" id="CVE-2023-4058" title="CVE-2023-4058" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4577" id="CVE-2023-4577" title="CVE-2023-4577" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4578" id="CVE-2023-4578" title="CVE-2023-4578" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4579" id="CVE-2023-4579" title="CVE-2023-4579" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4580" id="CVE-2023-4580" title="CVE-2023-4580" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4582" id="CVE-2023-4582" title="CVE-2023-4582" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4583" id="CVE-2023-4583" title="CVE-2023-4583" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4585" id="CVE-2023-4585" title="CVE-2023-4585" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5169" id="CVE-2023-5169" title="CVE-2023-5169" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5170" id="CVE-2023-5170" title="CVE-2023-5170" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5171" id="CVE-2023-5171" title="CVE-2023-5171" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5172" id="CVE-2023-5172" title="CVE-2023-5172" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5173" id="CVE-2023-5173" title="CVE-2023-5173" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5175" id="CVE-2023-5175" title="CVE-2023-5175" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5176" id="CVE-2023-5176" title="CVE-2023-5176" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5388" id="CVE-2023-5388" title="CVE-2023-5388" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5721" id="CVE-2023-5721" title="CVE-2023-5721" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5722" id="CVE-2023-5722" title="CVE-2023-5722" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5723" id="CVE-2023-5723" title="CVE-2023-5723" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5724" id="CVE-2023-5724" title="CVE-2023-5724" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5725" id="CVE-2023-5725" title="CVE-2023-5725" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5728" id="CVE-2023-5728" title="CVE-2023-5728" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5729" id="CVE-2023-5729" title="CVE-2023-5729" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5730" id="CVE-2023-5730" title="CVE-2023-5730" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5731" id="CVE-2023-5731" title="CVE-2023-5731" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5732" id="CVE-2023-5732" title="CVE-2023-5732" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6204" id="CVE-2023-6204" title="CVE-2023-6204" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6205" id="CVE-2023-6205" title="CVE-2023-6205" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6206" id="CVE-2023-6206" title="CVE-2023-6206" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6859" id="CVE-2023-6859" title="CVE-2023-6859" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6860" id="CVE-2023-6860" title="CVE-2023-6860" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6863" id="CVE-2023-6863" title="CVE-2023-6863" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6866" id="CVE-2023-6866" title="CVE-2023-6866" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6869" id="CVE-2023-6869" title="CVE-2023-6869" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0743" id="CVE-2024-0743" title="CVE-2024-0743" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0748" id="CVE-2024-0748" title="CVE-2024-0748" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0754" id="CVE-2024-0754" title="CVE-2024-0754" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-10458" id="CVE-2024-10458" title="CVE-2024-10458" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-10459" id="CVE-2024-10459" title="CVE-2024-10459" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-10460" id="CVE-2024-10460" title="CVE-2024-10460" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-10461" id="CVE-2024-10461" title="CVE-2024-10461" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-10462" id="CVE-2024-10462" title="CVE-2024-10462" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-10463" id="CVE-2024-10463" title="CVE-2024-10463" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-10464" id="CVE-2024-10464" title="CVE-2024-10464" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-10465" id="CVE-2024-10465" title="CVE-2024-10465" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-10466" id="CVE-2024-10466" title="CVE-2024-10466" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-10467" id="CVE-2024-10467" title="CVE-2024-10467" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-10941" id="CVE-2024-10941" title="CVE-2024-10941" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1547" id="CVE-2024-1547" title="CVE-2024-1547" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1548" id="CVE-2024-1548" title="CVE-2024-1548" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1549" id="CVE-2024-1549" title="CVE-2024-1549" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1550" id="CVE-2024-1550" title="CVE-2024-1550" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1551" id="CVE-2024-1551" title="CVE-2024-1551" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1553" id="CVE-2024-1553" title="CVE-2024-1553" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1554" id="CVE-2024-1554" title="CVE-2024-1554" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1555" id="CVE-2024-1555" title="CVE-2024-1555" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1556" id="CVE-2024-1556" title="CVE-2024-1556" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1557" id="CVE-2024-1557" title="CVE-2024-1557" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2606" id="CVE-2024-2606" title="CVE-2024-2606" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2607" id="CVE-2024-2607" title="CVE-2024-2607" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2608" id="CVE-2024-2608" title="CVE-2024-2608" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2609" id="CVE-2024-2609" title="CVE-2024-2609" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2610" id="CVE-2024-2610" title="CVE-2024-2610" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2611" id="CVE-2024-2611" title="CVE-2024-2611" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2612" id="CVE-2024-2612" title="CVE-2024-2612" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2613" id="CVE-2024-2613" title="CVE-2024-2613" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2614" id="CVE-2024-2614" title="CVE-2024-2614" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2615" id="CVE-2024-2615" title="CVE-2024-2615" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2616" id="CVE-2024-2616" title="CVE-2024-2616" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29943" id="CVE-2024-29943" title="CVE-2024-29943" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29944" id="CVE-2024-29944" title="CVE-2024-29944" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3302" id="CVE-2024-3302" title="CVE-2024-3302" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3852" id="CVE-2024-3852" title="CVE-2024-3852" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3853" id="CVE-2024-3853" title="CVE-2024-3853" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3854" id="CVE-2024-3854" title="CVE-2024-3854" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3855" id="CVE-2024-3855" title="CVE-2024-3855" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3856" id="CVE-2024-3856" title="CVE-2024-3856" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3857" id="CVE-2024-3857" title="CVE-2024-3857" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3858" id="CVE-2024-3858" title="CVE-2024-3858" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3859" id="CVE-2024-3859" title="CVE-2024-3859" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3860" id="CVE-2024-3860" title="CVE-2024-3860" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3861" id="CVE-2024-3861" title="CVE-2024-3861" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3862" id="CVE-2024-3862" title="CVE-2024-3862" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3864" id="CVE-2024-3864" title="CVE-2024-3864" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3865" id="CVE-2024-3865" title="CVE-2024-3865" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43097" id="CVE-2024-43097" title="CVE-2024-43097" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4367" id="CVE-2024-4367" title="CVE-2024-4367" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4764" id="CVE-2024-4764" title="CVE-2024-4764" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4767" id="CVE-2024-4767" title="CVE-2024-4767" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4768" id="CVE-2024-4768" title="CVE-2024-4768" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4769" id="CVE-2024-4769" title="CVE-2024-4769" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4770" id="CVE-2024-4770" title="CVE-2024-4770" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4771" id="CVE-2024-4771" title="CVE-2024-4771" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4772" id="CVE-2024-4772" title="CVE-2024-4772" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4773" id="CVE-2024-4773" title="CVE-2024-4773" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4775" id="CVE-2024-4775" title="CVE-2024-4775" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4776" id="CVE-2024-4776" title="CVE-2024-4776" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4777" id="CVE-2024-4777" title="CVE-2024-4777" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4778" id="CVE-2024-4778" title="CVE-2024-4778" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5688" id="CVE-2024-5688" title="CVE-2024-5688" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5690" id="CVE-2024-5690" title="CVE-2024-5690" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5691" id="CVE-2024-5691" title="CVE-2024-5691" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5693" id="CVE-2024-5693" title="CVE-2024-5693" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5696" id="CVE-2024-5696" title="CVE-2024-5696" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5697" id="CVE-2024-5697" title="CVE-2024-5697" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6601" id="CVE-2024-6601" title="CVE-2024-6601" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6602" id="CVE-2024-6602" title="CVE-2024-6602" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6603" id="CVE-2024-6603" title="CVE-2024-6603" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6604" id="CVE-2024-6604" title="CVE-2024-6604" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6605" id="CVE-2024-6605" title="CVE-2024-6605" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6606" id="CVE-2024-6606" title="CVE-2024-6606" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6607" id="CVE-2024-6607" title="CVE-2024-6607" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6608" id="CVE-2024-6608" title="CVE-2024-6608" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6609" id="CVE-2024-6609" title="CVE-2024-6609" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6610" id="CVE-2024-6610" title="CVE-2024-6610" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6611" id="CVE-2024-6611" title="CVE-2024-6611" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6612" id="CVE-2024-6612" title="CVE-2024-6612" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6613" id="CVE-2024-6613" title="CVE-2024-6613" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6614" id="CVE-2024-6614" title="CVE-2024-6614" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6615" id="CVE-2024-6615" title="CVE-2024-6615" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-7519" id="CVE-2024-7519" title="CVE-2024-7519" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-7521" id="CVE-2024-7521" title="CVE-2024-7521" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-7522" id="CVE-2024-7522" title="CVE-2024-7522" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-7524" id="CVE-2024-7524" title="CVE-2024-7524" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-7525" id="CVE-2024-7525" title="CVE-2024-7525" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-7526" id="CVE-2024-7526" title="CVE-2024-7526" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-7527" id="CVE-2024-7527" title="CVE-2024-7527" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-7529" id="CVE-2024-7529" title="CVE-2024-7529" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-7531" id="CVE-2024-7531" title="CVE-2024-7531" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-7652" id="CVE-2024-7652" title="CVE-2024-7652" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-8381" id="CVE-2024-8381" title="CVE-2024-8381" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-8382" id="CVE-2024-8382" title="CVE-2024-8382" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-8383" id="CVE-2024-8383" title="CVE-2024-8383" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-8384" id="CVE-2024-8384" title="CVE-2024-8384" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-9392" id="CVE-2024-9392" title="CVE-2024-9392" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-9393" id="CVE-2024-9393" title="CVE-2024-9393" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-9394" id="CVE-2024-9394" title="CVE-2024-9394" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-9396" id="CVE-2024-9396" title="CVE-2024-9396" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-9397" id="CVE-2024-9397" title="CVE-2024-9397" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-9398" id="CVE-2024-9398" title="CVE-2024-9398" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-9399" id="CVE-2024-9399" title="CVE-2024-9399" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-9400" id="CVE-2024-9400" title="CVE-2024-9400" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-9401" id="CVE-2024-9401" title="CVE-2024-9401" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-9402" id="CVE-2024-9402" title="CVE-2024-9402" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-9680" id="CVE-2024-9680" title="CVE-2024-9680" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1931" id="CVE-2025-1931" title="CVE-2025-1931" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1932" id="CVE-2025-1932" title="CVE-2025-1932" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1933" id="CVE-2025-1933" title="CVE-2025-1933" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1934" id="CVE-2025-1934" title="CVE-2025-1934" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1935" id="CVE-2025-1935" title="CVE-2025-1935" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1936" id="CVE-2025-1936" title="CVE-2025-1936" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1937" id="CVE-2025-1937" title="CVE-2025-1937" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1938" id="CVE-2025-1938" title="CVE-2025-1938" type="cve"></reference>
          </references>
          <description>When loading a script with Subresource Integrity, attackers with an injection capability could trigger the reuse of previously cached entries with incorrect, different integrity metadata. This vulnerability affects Firefox &lt; 103.(CVE-2022-36315)When using the Performance API, an attacker was able to notice subtle differences between PerformanceEntries and thus learn whether the target URL had been subject to a redirect. This vulnerability affects Firefox &lt; 103.(CVE-2022-36316)An attacker could have written a value to the first element in a zero-length JavaScript array. Although the array was zero-length, the value was not written to an invalid memory address. This vulnerability affects Firefox &lt; 104.(CVE-2022-38475)Service Workers did not detect Private Browsing Mode correctly in all cases, which could have led to Service Workers being written to disk for websites visited in Private Browsing Mode. This would not have persisted them in a state where they would run again, but it would have leaked Private Browsing Mode details to disk. This vulnerability affects Firefox &lt; 107.(CVE-2022-45417)If the user added a security exception for an invalid TLS certificate, opened an ongoing TLS connection with a server that used that certificate, and then deleted the exception, Firefox would have kept the connection alive, making it seem like the certificate was still trusted. This vulnerability affects Firefox &lt; 107.(CVE-2022-45419)Mozilla developers and community members Lukas Bernhard, Gabriele Svelto, Randell Jesup, and the Mozilla Fuzzing Team reported memory safety bugs present in Firefox 107. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 108.(CVE-2022-46879)Mozilla developers Gabriele Svelto, Yulia Startsev, Andrew McCreight and the Mozilla Fuzzing Team reported memory safety bugs present in Firefox 106. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code.&lt;br /&gt;*Note*: This advisory was added on December 13th, 2022 after discovering it was inadvertently left out of the original advisory. The fix was included in the original release of Firefox 107. This vulnerability affects Firefox &lt; 107.(CVE-2022-46883)Due to URL previews in the network panel of developer tools improperly storing URLs, query parameters could potentially be used to overwrite global objects in privileged code. This vulnerability affects Firefox &lt; 110.(CVE-2023-25731)The return value from `gfx::SourceSurfaceSkia::Map()` wasn&#39;t being verified which could have potentially lead to a null pointer dereference. This vulnerability affects Firefox &lt; 110.(CVE-2023-25733)An invalid downcast from `nsHTMLDocument` to `nsIContent` could have lead to undefined behavior. This vulnerability affects Firefox &lt; 110.(CVE-2023-25736)Under certain circumstances, a ServiceWorker&#39;s offline cache may have leaked to the file system when using private browsing mode. This vulnerability affects Firefox &lt; 111.(CVE-2023-25750)When following a redirect to a publicly accessible web extension file, the URL may have been translated to the actual local path, leaking potentially sensitive information. This vulnerability affects Firefox &lt; 111.(CVE-2023-28160)Memory safety bugs present in Firefox 110. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 111.(CVE-2023-28177)Multiple race conditions in the font initialization could have led to memory corruption and execution of attacker-controlled code. This vulnerability affects Firefox for Android &lt; 112, Firefox &lt; 112, and Focus for Android &lt; 112.(CVE-2023-29537)Under specific circumstances a WebExtension may have received a &lt;code&gt;jar:file:///&lt;/code&gt; URI instead of a &lt;code&gt;moz-extension:///&lt;/code&gt; URI during a load request. This leaked directory paths on the user&#39;s machine. This vulnerability affects Firefox for Android &lt; 112, Firefox &lt; 112, and Focus for Android &lt; 112.(CVE-2023-29538)Using a redirect embedded into &lt;code&gt;sourceMappingUrls&lt;/code&gt; could allow for navigation to external protocol links in sandboxed iframes without &lt;code&gt;allow-top-navigation-to-custom-protocols&lt;/code&gt;. This vulnerability affects Firefox for Android &lt; 112, Firefox &lt; 112, and Focus for Android &lt; 112.(CVE-2023-29540)When a secure cookie existed in the Firefox cookie jar an insecure cookie for the same domain could have been created, when it should have silently failed. This could have led to a desynchronization in expected results when reading from the secure cookie. This vulnerability affects Firefox for Android &lt; 112, Firefox &lt; 112, and Focus for Android &lt; 112.(CVE-2023-29547)Under certain circumstances, a call to the &lt;code&gt;bind&lt;/code&gt; function may have resulted in the incorrect realm. This may have created a vulnerability relating to JavaScript-implemented sandboxes such as SES. This vulnerability affects Firefox for Android &lt; 112, Firefox &lt; 112, and Focus for Android &lt; 112.(CVE-2023-29549)Service workers could reveal script base URL due to dynamic `import()`. This vulnerability affects Firefox &lt; 113.(CVE-2023-32208)A maliciously crafted favicon could have led to an out of memory crash. This vulnerability affects Firefox &lt; 113.(CVE-2023-32209)Documents were incorrectly assuming an ordering of principal objects when ensuring we were loading an appropriately privileged principal. In certain circumstances it might have been possible to cause a document to be loaded with a higher privileged principal than intended. This vulnerability affects Firefox &lt; 113.(CVE-2023-32210)When choosing a site-isolated process for a document loaded from a data: URL that was the result of a redirect, Firefox would load that document in the same process as the site that issued the redirect. This bypassed the site-isolation protections against Spectre-like attacks on sites that host an &#34;open redirect&#34;. Firefox no longer follows HTTP redirects to data: URLs. This vulnerability affects Firefox &lt; 114.(CVE-2023-34415)Memory safety bugs present in Firefox 113. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 114.(CVE-2023-34417)When Firefox is configured to block storage of all cookies, it was still possible to store data in localstorage by using an iframe with a source of &#39;about:blank&#39;. This could have led to malicious websites storing tracking data without permission. This vulnerability affects Firefox &lt; 115.(CVE-2023-3482)During the worker lifecycle, a use-after-free condition could have occured, which could have led to a potentially exploitable crash. This vulnerability affects Firefox &lt; 115.0.2, Firefox ESR &lt; 115.0.2, and Thunderbird &lt; 115.0.1.(CVE-2023-3600)Insufficient validation in the Drag and Drop API in conjunction with social engineering, may have allowed an attacker to trick end-users into creating a shortcut to local system files.  This could have been leveraged to execute arbitrary code. This vulnerability affects Firefox &lt; 115.(CVE-2023-37203)A website could have obscured the fullscreen notification by using an option element by introducing lag via an expensive computational function. This could have led to user confusion and possible spoofing attacks. This vulnerability affects Firefox &lt; 115.(CVE-2023-37204)The use of RTL Arabic characters in the address bar may have allowed for URL spoofing. This vulnerability affects Firefox &lt; 115.(CVE-2023-37205)Uploading files which contain symlinks may have allowed an attacker to trick a user into submitting sensitive data to a malicious website. This vulnerability affects Firefox &lt; 115.(CVE-2023-37206)A use-after-free condition existed in `NotifyOnHistoryReload` where a `LoadingSessionHistoryEntry` object was freed and a reference to that object remained.  This resulted in a potentially exploitable condition when the reference to that object was later reused. This vulnerability affects Firefox &lt; 115.(CVE-2023-37209)A website could prevent a user from exiting full-screen mode via alert and prompt calls.  This could lead to user confusion and possible spoofing attacks. This vulnerability affects Firefox &lt; 115.(CVE-2023-37210)Memory safety bugs present in Firefox 114. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 115.(CVE-2023-37212)A website could have obscured the full screen notification by using the file open dialog. This could have led to user confusion and possible spoofing attacks. This vulnerability affects Firefox &lt; 116, Firefox ESR &lt; 115.2, and Thunderbird &lt; 115.2.(CVE-2023-4051)A website could have obscured the full screen notification by using a URL with a scheme handled by an external program, such as a mailto URL. This could have led to user confusion and possible spoofing attacks. This vulnerability affects Firefox &lt; 116, Firefox ESR &lt; 115.2, and Thunderbird &lt; 115.2.(CVE-2023-4053)Memory safety bugs present in Firefox 115. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 116.(CVE-2023-4058)When `UpdateRegExpStatics` attempted to access `initialStringHeap` it could already have been garbage collected prior to entering the function, which could potentially have led to an exploitable crash. This vulnerability affects Firefox &lt; 117, Firefox ESR &lt; 115.2, and Thunderbird &lt; 115.2.(CVE-2023-4577)When calling `JS::CheckRegExpSyntax` a Syntax Error could have been set which would end in calling `convertToRuntimeErrorAndClear`. A path in the function could attempt to allocate memory when none is available which would have caused a newly created Out of Memory exception to be mishandled as a Syntax Error. This vulnerability affects Firefox &lt; 117, Firefox ESR &lt; 115.2, and Thunderbird &lt; 115.2.(CVE-2023-4578)Search queries in the default search engine could appear to have been the currently navigated URL if the search query itself was a well formed URL. This could have led to a site spoofing another if it had been maliciously set as the default search engine. This vulnerability affects Firefox &lt; 117.(CVE-2023-4579)Push notifications stored on disk in private browsing mode were not being encrypted potentially allowing the leak of sensitive information. This vulnerability affects Firefox &lt; 117, Firefox ESR &lt; 115.2, and Thunderbird &lt; 115.2.(CVE-2023-4580)Due to large allocation checks in Angle for glsl shaders being too lenient a buffer overflow could have occured when allocating too much private shader memory on mac OS. *This bug only affects Firefox on macOS. Other operating systems are unaffected.* This vulnerability affects Firefox &lt; 117, Firefox ESR &lt; 115.2, and Thunderbird &lt; 115.2.(CVE-2023-4582)When checking if the Browsing Context had been discarded in `HttpBaseChannel`, if the load group was not available then it was assumed to have already been discarded which was not always the case for private channels after the private session had ended. This vulnerability affects Firefox &lt; 117, Firefox ESR &lt; 115.2, and Thunderbird &lt; 115.2.(CVE-2023-4583)Memory safety bugs present in Firefox 116, Firefox ESR 115.1, and Thunderbird 115.1. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 117, Firefox ESR &lt; 115.2, and Thunderbird &lt; 115.2.(CVE-2023-4585)A compromised content process could have provided malicious data in a `PathRecording` resulting in an out-of-bounds write, leading to a potentially exploitable crash in a privileged process. This vulnerability affects Firefox &lt; 118, Firefox ESR &lt; 115.3, and Thunderbird &lt; 115.3.(CVE-2023-5169)In canvas rendering, a compromised content process could have caused a surface to change unexpectedly, leading to a memory leak of a privileged process. This memory leak could be used to effect a sandbox escape if the correct data was leaked. This vulnerability affects Firefox &lt; 118.(CVE-2023-5170)During Ion compilation, a Garbage Collection could have resulted in a use-after-free condition, allowing an attacker to write two NUL bytes, and cause a potentially exploitable crash. This vulnerability affects Firefox &lt; 118, Firefox ESR &lt; 115.3, and Thunderbird &lt; 115.3.(CVE-2023-5171)A hashtable  in the Ion Engine could have been mutated while there was a live interior reference, leading to a potential use-after-free and exploitable crash. This vulnerability affects Firefox &lt; 118.(CVE-2023-5172)In a non-standard configuration of Firefox, an integer overflow could have occurred based on network traffic (possibly under influence of a local unprivileged webpage), leading to an out-of-bounds write to privileged process memory. *This bug only affects Firefox if a non-standard preference allowing non-HTTPS Alternate Services (`network.http.altsvc.oe`) is enabled.* This vulnerability affects Firefox &lt; 118.(CVE-2023-5173)During process shutdown, it was possible that an `ImageBitmap` was created that would later be used after being freed from a different codepath, leading to a potentially exploitable crash. This vulnerability affects Firefox &lt; 118.(CVE-2023-5175)Memory safety bugs present in Firefox 117, Firefox ESR 115.2, and Thunderbird 115.2. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 118, Firefox ESR &lt; 115.3, and Thunderbird &lt; 115.3.(CVE-2023-5176)NSS was susceptible to a timing side-channel attack when performing RSA decryption. This attack could potentially allow an attacker to recover the private data. This vulnerability affects Firefox &lt; 124, Firefox ESR &lt; 115.9, and Thunderbird &lt; 115.9.(CVE-2023-5388)It was possible for certain browser prompts and dialogs to be activated or dismissed unintentionally by the user due to an insufficient activation-delay. This vulnerability affects Firefox &lt; 119, Firefox ESR &lt; 115.4, and Thunderbird &lt; 115.4.1.(CVE-2023-5721)Using iterative requests an attacker was able to learn the size of an opaque response, as well as the contents of a server-supplied Vary header. This vulnerability affects Firefox &lt; 119.(CVE-2023-5722)An attacker with temporary script access to a site could have set a cookie containing invalid characters using `document.cookie` that could have led to unknown errors. This vulnerability affects Firefox &lt; 119.(CVE-2023-5723)Drivers are not always robust to extremely large draw calls and in some cases this scenario could have led to a crash. This vulnerability affects Firefox &lt; 119, Firefox ESR &lt; 115.4, and Thunderbird &lt; 115.4.1.(CVE-2023-5724)A malicious installed WebExtension could open arbitrary URLs, which under the right circumstance could be leveraged to collect sensitive user data. This vulnerability affects Firefox &lt; 119, Firefox ESR &lt; 115.4, and Thunderbird &lt; 115.4.1.(CVE-2023-5725)During garbage collection extra operations were performed on a object that should not be. This could have led to a potentially exploitable crash. This vulnerability affects Firefox &lt; 119, Firefox ESR &lt; 115.4, and Thunderbird &lt; 115.4.1.(CVE-2023-5728)A malicious web site can enter fullscreen mode while simultaneously triggering a WebAuthn prompt. This could have obscured the fullscreen notification and could have been leveraged in a spoofing attack. This vulnerability affects Firefox &lt; 119.(CVE-2023-5729)Memory safety bugs present in Firefox 118, Firefox ESR 115.3, and Thunderbird 115.3. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 119, Firefox ESR &lt; 115.4, and Thunderbird &lt; 115.4.1.(CVE-2023-5730)Memory safety bugs present in Firefox 118. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 119.(CVE-2023-5731)An attacker could have created a malicious link using bidirectional characters to spoof the location in the address bar when visited. This vulnerability affects Firefox &lt; 117, Firefox ESR &lt; 115.4, and Thunderbird &lt; 115.4.1.(CVE-2023-5732)On some systems—depending on the graphics settings and drivers—it was possible to force an out-of-bounds read and leak memory data into the images created on the canvas element. This vulnerability affects Firefox &lt; 120, Firefox ESR &lt; 115.5.0, and Thunderbird &lt; 115.5.(CVE-2023-6204)It was possible to cause the use of a MessagePort after it had already been freed, which could potentially have led to an exploitable crash. This vulnerability affects Firefox &lt; 120, Firefox ESR &lt; 115.5.0, and Thunderbird &lt; 115.5.(CVE-2023-6205)The black fade animation when exiting fullscreen is roughly the length of the anti-clickjacking delay on permission prompts. It was possible to use this fact to surprise users by luring them to click where the permission grant button would be about to appear. This vulnerability affects Firefox &lt; 120, Firefox ESR &lt; 115.5.0, and Thunderbird &lt; 115.5.(CVE-2023-6206)A use-after-free condition affected TLS socket creation when under memory pressure. This vulnerability affects Firefox ESR &lt; 115.6, Thunderbird &lt; 115.6, and Firefox &lt; 121.(CVE-2023-6859)The `VideoBridge` allowed any content process to use textures produced by remote decoders.  This could be abused to escape the sandbox. This vulnerability affects Firefox ESR &lt; 115.6, Thunderbird &lt; 115.6, and Firefox &lt; 121.(CVE-2023-6860)The `ShutdownObserver()` was susceptible to potentially undefined behavior due to its reliance on a dynamic type that lacked a virtual destructor. This vulnerability affects Firefox ESR &lt; 115.6, Thunderbird &lt; 115.6, and Firefox &lt; 121.(CVE-2023-6863)TypedArrays can be fallible and lacked proper exception handling. This could lead to abuse in other APIs which expect TypedArrays to always succeed. This vulnerability affects Firefox &lt; 121.(CVE-2023-6866)A `&lt;dialog&gt;` element could have been manipulated to paint content outside of a sandboxed iframe. This could allow untrusted content to display under the guise of trusted content. This vulnerability affects Firefox &lt; 121.(CVE-2023-6869)An unchecked return value in TLS handshake code could have caused a potentially exploitable crash. This vulnerability affects Firefox &lt; 122, Firefox ESR &lt; 115.9, and Thunderbird &lt; 115.9.(CVE-2024-0743)A compromised content process could have updated the document URI. This could have allowed an attacker to set an arbitrary URI in the address bar or history. This vulnerability affects Firefox &lt; 122.(CVE-2024-0748)Some WASM source files could have caused a crash when loaded in devtools. This vulnerability affects Firefox &lt; 122.(CVE-2024-0754)A permission leak could have occurred from a trusted site to an untrusted site via `embed` or `object` elements. This vulnerability affects Firefox &lt; 132, Firefox ESR &lt; 128.4, Firefox ESR &lt; 115.17, Thunderbird &lt; 128.4, and Thunderbird &lt; 132.(CVE-2024-10458)An attacker could have caused a use-after-free when accessibility was enabled, leading to a potentially exploitable crash. This vulnerability affects Firefox &lt; 132, Firefox ESR &lt; 128.4, Firefox ESR &lt; 115.17, Thunderbird &lt; 128.4, and Thunderbird &lt; 132.(CVE-2024-10459)The origin of an external protocol handler prompt could have been obscured using a data: URL within an `iframe`. This vulnerability affects Firefox &lt; 132, Firefox ESR &lt; 128.4, Thunderbird &lt; 128.4, and Thunderbird &lt; 132.(CVE-2024-10460)In multipart/x-mixed-replace responses, `Content-Disposition: attachment` in the response header was not respected and did not force a download, which could allow XSS attacks. This vulnerability affects Firefox &lt; 132, Firefox ESR &lt; 128.4, Thunderbird &lt; 128.4, and Thunderbird &lt; 132.(CVE-2024-10461)Truncation of a long URL could have allowed origin spoofing in a permission prompt. This vulnerability affects Firefox &lt; 132, Firefox ESR &lt; 128.4, Thunderbird &lt; 128.4, and Thunderbird &lt; 132.(CVE-2024-10462)Video frames could have been leaked between origins in some situations. This vulnerability affects Firefox &lt; 132, Firefox ESR &lt; 128.4, Firefox ESR &lt; 115.17, Thunderbird &lt; 128.4, and Thunderbird &lt; 132.(CVE-2024-10463)Repeated writes to history interface attributes could have been used to cause a Denial of Service condition in the browser. This was addressed by introducing rate-limiting to this API. This vulnerability affects Firefox &lt; 132, Firefox ESR &lt; 128.4, Thunderbird &lt; 128.4, and Thunderbird &lt; 132.(CVE-2024-10464)A clipboard &#34;paste&#34; button could persist across tabs which allowed a spoofing attack. This vulnerability affects Firefox &lt; 132, Firefox ESR &lt; 128.4, Thunderbird &lt; 128.4, and Thunderbird &lt; 132.(CVE-2024-10465)By sending a specially crafted push message, a remote server could have hung the parent process, causing the browser to become unresponsive. This vulnerability affects Firefox &lt; 132, Firefox ESR &lt; 128.4, Thunderbird &lt; 128.4, and Thunderbird &lt; 132.(CVE-2024-10466)Memory safety bugs present in Firefox 131, Firefox ESR 128.3, and Thunderbird 128.3. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 132, Firefox ESR &lt; 128.4, Thunderbird &lt; 128.4, and Thunderbird &lt; 132.(CVE-2024-10467)A malicious website could have included an iframe with an malformed URI resulting in a non-exploitable browser crash. This vulnerability affects Firefox &lt; 126.(CVE-2024-10941)Through a series of API calls and redirects, an attacker-controlled alert dialog could have been displayed on another website (with the victim website&#39;s URL shown). This vulnerability affects Firefox &lt; 123, Firefox ESR &lt; 115.8, and Thunderbird &lt; 115.8.(CVE-2024-1547)A website could have obscured the fullscreen notification by using a dropdown select input element. This could have led to user confusion and possible spoofing attacks. This vulnerability affects Firefox &lt; 123, Firefox ESR &lt; 115.8, and Thunderbird &lt; 115.8.(CVE-2024-1548)If a website set a large custom cursor, portions of the cursor could have overlapped with the permission dialog, potentially resulting in user confusion and unexpected granted permissions. This vulnerability affects Firefox &lt; 123, Firefox ESR &lt; 115.8, and Thunderbird &lt; 115.8.(CVE-2024-1549)A malicious website could have used a combination of exiting fullscreen mode and `requestPointerLock` to cause the user&#39;s mouse to be re-positioned unexpectedly, which could have led to user confusion and inadvertently granting permissions they did not intend to grant. This vulnerability affects Firefox &lt; 123, Firefox ESR &lt; 115.8, and Thunderbird &lt; 115.8.(CVE-2024-1550)Set-Cookie response headers were being incorrectly honored in multipart HTTP responses. If an attacker could control the Content-Type response header, as well as control part of the response body, they could inject Set-Cookie response headers that would have been honored by the browser. This vulnerability affects Firefox &lt; 123, Firefox ESR &lt; 115.8, and Thunderbird &lt; 115.8.(CVE-2024-1551)Memory safety bugs present in Firefox 122, Firefox ESR 115.7, and Thunderbird 115.7. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 123, Firefox ESR &lt; 115.8, and Thunderbird &lt; 115.8.(CVE-2024-1553)The `fetch()` API and navigation incorrectly shared the same cache, as the cache key did not include the optional headers `fetch()` may contain.  Under the correct circumstances, an attacker may have been able to poison the local browser cache by priming it with a `fetch()` response controlled by the additional headers. Upon navigation to the same URL, the user would see the cached response instead of the expected response. This vulnerability affects Firefox &lt; 123.(CVE-2024-1554)When opening a website using the `firefox://` protocol handler, SameSite cookies were not properly respected. This vulnerability affects Firefox &lt; 123.(CVE-2024-1555)The incorrect object was checked for NULL in the built-in profiler, potentially leading to invalid memory access and undefined behavior. *Note:* This issue only affects the application when the profiler is running. This vulnerability affects Firefox &lt; 123.(CVE-2024-1556)Memory safety bugs present in Firefox 122. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 123.(CVE-2024-1557)Passing invalid data could have led to invalid wasm values being created, such as arbitrary integers turning into pointer values. This vulnerability affects Firefox &lt; 124.(CVE-2024-2606)Return registers were overwritten which could have allowed an attacker to execute arbitrary code. *Note:* This issue only affected Armv7-A systems. Other operating systems are unaffected. This vulnerability affects Firefox &lt; 124, Firefox ESR &lt; 115.9, and Thunderbird &lt; 115.9.(CVE-2024-2607)`AppendEncodedAttributeValue(), ExtraSpaceNeededForAttrEncoding()` and `AppendEncodedCharacters()` could have experienced integer overflows, causing underallocation of an output buffer leading to an out of bounds write. This vulnerability affects Firefox &lt; 124, Firefox ESR &lt; 115.9, and Thunderbird &lt; 115.9.(CVE-2024-2608)The permission prompt input delay could expire while the window is not in focus. This makes it vulnerable to clickjacking by malicious websites. This vulnerability affects Firefox &lt; 124, Firefox ESR &lt; 115.10, and Thunderbird &lt; 115.10.(CVE-2024-2609)Using a markup injection an attacker could have stolen nonce values. This could have been used to bypass strict content security policies. This vulnerability affects Firefox &lt; 124, Firefox ESR &lt; 115.9, and Thunderbird &lt; 115.9.(CVE-2024-2610)A missing delay on when pointer lock was used could have allowed a malicious page to trick a user into granting permissions. This vulnerability affects Firefox &lt; 124, Firefox ESR &lt; 115.9, and Thunderbird &lt; 115.9.(CVE-2024-2611)If an attacker could find a way to trigger a particular code path in `SafeRefPtr`, it could have triggered a crash or potentially be leveraged to achieve code execution. This vulnerability affects Firefox &lt; 124, Firefox ESR &lt; 115.9, and Thunderbird &lt; 115.9.(CVE-2024-2612)Data was not properly sanitized when decoding a QUIC ACK frame; this could have led to unrestricted memory consumption and a crash. This vulnerability affects Firefox &lt; 124.(CVE-2024-2613)Memory safety bugs present in Firefox 123, Firefox ESR 115.8, and Thunderbird 115.8. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 124, Firefox ESR &lt; 115.9, and Thunderbird &lt; 115.9.(CVE-2024-2614)Memory safety bugs present in Firefox 123. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 124.(CVE-2024-2615)To harden ICU against exploitation, the behavior for out-of-memory conditions was changed to crash instead of attempt to continue. This vulnerability affects Firefox ESR &lt; 115.9 and Thunderbird &lt; 115.9.(CVE-2024-2616)An attacker was able to perform an out-of-bounds read or write on a JavaScript object by fooling range-based bounds check elimination. This vulnerability affects Firefox &lt; 124.0.1.(CVE-2024-29943)An attacker was able to inject an event handler into a privileged object that would allow arbitrary JavaScript execution in the parent process. Note: This vulnerability affects Desktop Firefox only, it does not affect mobile versions of Firefox. This vulnerability affects Firefox &lt; 124.0.1 and Firefox ESR &lt; 115.9.1.(CVE-2024-29944)There was no limit to the number of HTTP/2 CONTINUATION frames that would be processed. A server could abuse this to create an Out of Memory condition in the browser. This vulnerability affects Firefox &lt; 125, Firefox ESR &lt; 115.10, and Thunderbird &lt; 115.10.(CVE-2024-3302)GetBoundName could return the wrong version of an object when JIT optimizations were applied. This vulnerability affects Firefox &lt; 125, Firefox ESR &lt; 115.10, and Thunderbird &lt; 115.10.(CVE-2024-3852)A use-after-free could result if a JavaScript realm was in the process of being initialized when a garbage collection started. This vulnerability affects Firefox &lt; 125.(CVE-2024-3853)In some code patterns the JIT incorrectly optimized switch statements and generated code with out-of-bounds-reads. This vulnerability affects Firefox &lt; 125, Firefox ESR &lt; 115.10, and Thunderbird &lt; 115.10.(CVE-2024-3854)In certain cases the JIT incorrectly optimized MSubstr operations, which led to out-of-bounds reads. This vulnerability affects Firefox &lt; 125.(CVE-2024-3855)A use-after-free could occur during WASM execution if garbage collection ran during the creation of an array. This vulnerability affects Firefox &lt; 125.(CVE-2024-3856)The JIT created incorrect code for arguments in certain cases. This led to potential use-after-free crashes during garbage collection. This vulnerability affects Firefox &lt; 125, Firefox ESR &lt; 115.10, and Thunderbird &lt; 115.10.(CVE-2024-3857)It was possible to mutate a JavaScript object so that the JIT could crash while tracing it. This vulnerability affects Firefox &lt; 125.(CVE-2024-3858)On 32-bit versions there were integer-overflows that led to an out-of-bounds-read that potentially could be triggered by a malformed OpenType font. This vulnerability affects Firefox &lt; 125, Firefox ESR &lt; 115.10, and Thunderbird &lt; 115.10.(CVE-2024-3859)An out-of-memory condition during object initialization could result in an empty shape list. If the JIT subsequently traced the object it would crash. This vulnerability affects Firefox &lt; 125.(CVE-2024-3860)If an AlignedBuffer were assigned to itself, the subsequent self-move could result in an incorrect reference count and later use-after-free. This vulnerability affects Firefox &lt; 125, Firefox ESR &lt; 115.10, and Thunderbird &lt; 115.10.(CVE-2024-3861)The MarkStack assignment operator, part of the JavaScript engine, could access uninitialized memory if it were used in a self-assignment. This vulnerability affects Firefox &lt; 125.(CVE-2024-3862)Memory safety bug present in Firefox 124, Firefox ESR 115.9, and Thunderbird 115.9. This bug showed evidence of memory corruption and we presume that with enough effort this could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 125, Firefox ESR &lt; 115.10, and Thunderbird &lt; 115.10.(CVE-2024-3864)Memory safety bugs present in Firefox 124. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 125.(CVE-2024-3865)In resizeToAtLeast of SkRegion.cpp, there is a possible out of bounds write due to an integer overflow. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.(CVE-2024-43097)A type check was missing when handling fonts in PDF.js, which would allow arbitrary JavaScript execution in the PDF.js context. This vulnerability affects Firefox &lt; 126, Firefox ESR &lt; 115.11, and Thunderbird &lt; 115.11.(CVE-2024-4367)Multiple WebRTC threads could have claimed a newly connected audio input leading to use-after-free. This vulnerability affects Firefox &lt; 126.(CVE-2024-4764)If the `browser.privatebrowsing.autostart` preference is enabled, IndexedDB files were not properly deleted when the window was closed. This preference is disabled by default in Firefox. This vulnerability affects Firefox &lt; 126, Firefox ESR &lt; 115.11, and Thunderbird &lt; 115.11.(CVE-2024-4767)A bug in popup notifications&#39; interaction with WebAuthn made it easier for an attacker to trick a user into granting permissions. This vulnerability affects Firefox &lt; 126, Firefox ESR &lt; 115.11, and Thunderbird &lt; 115.11.(CVE-2024-4768)When importing resources using Web Workers, error messages would distinguish the difference between `application/javascript` responses and non-script responses.  This could have been abused to learn information cross-origin. This vulnerability affects Firefox &lt; 126, Firefox ESR &lt; 115.11, and Thunderbird &lt; 115.11.(CVE-2024-4769)When saving a page to PDF, certain font styles could have led to a potential use-after-free crash. This vulnerability affects Firefox &lt; 126, Firefox ESR &lt; 115.11, and Thunderbird &lt; 115.11.(CVE-2024-4770)A memory allocation check was missing which would lead to a use-after-free if the allocation failed. This could have triggered a crash or potentially be leveraged to achieve code execution. This vulnerability affects Firefox &lt; 126.(CVE-2024-4771)An HTTP digest authentication nonce value was generated using `rand()` which could lead to predictable values. This vulnerability affects Firefox &lt; 126.(CVE-2024-4772)When a network error occurred during page load, the prior content could have remained in view with a blank URL bar. This could have been used to obfuscate a spoofed web site. This vulnerability affects Firefox &lt; 126.(CVE-2024-4773)An iterator stop condition was missing when handling WASM code in the built-in profiler, potentially leading to invalid memory access and undefined behavior. *Note:* This issue only affects the application when the profiler is running. This vulnerability affects Firefox &lt; 126.(CVE-2024-4775)A file dialog shown while in full-screen mode could have resulted in the window remaining disabled. This vulnerability affects Firefox &lt; 126.(CVE-2024-4776)Memory safety bugs present in Firefox 125, Firefox ESR 115.10, and Thunderbird 115.10. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 126, Firefox ESR &lt; 115.11, and Thunderbird &lt; 115.11.(CVE-2024-4777)Memory safety bugs present in Firefox 125. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 126.(CVE-2024-4778)If a garbage collection was triggered at the right time, a use-after-free could have occurred during object transplant. This vulnerability affects Firefox &lt; 127, Firefox ESR &lt; 115.12, and Thunderbird &lt; 115.12.(CVE-2024-5688)By monitoring the time certain operations take, an attacker could have guessed which external protocol handlers were functional on a user&#39;s system. This vulnerability affects Firefox &lt; 127, Firefox ESR &lt; 115.12, and Thunderbird &lt; 115.12.(CVE-2024-5690)By tricking the browser with a `X-Frame-Options` header, a sandboxed iframe could have presented a button that, if clicked by a user, would bypass restrictions to open a new window. This vulnerability affects Firefox &lt; 127, Firefox ESR &lt; 115.12, and Thunderbird &lt; 115.12.(CVE-2024-5691)Offscreen Canvas did not properly track cross-origin tainting, which could be used to access image data from another site in violation of same-origin policy. This vulnerability affects Firefox &lt; 127, Firefox ESR &lt; 115.12, and Thunderbird &lt; 115.12.(CVE-2024-5693)By manipulating the text in an `&lt;input&gt;` tag, an attacker could have caused corrupt memory leading to a potentially exploitable crash. This vulnerability affects Firefox &lt; 127, Firefox ESR &lt; 115.12, and Thunderbird &lt; 115.12.(CVE-2024-5696)A website was able to detect when a user took a screenshot of a page using the built-in Screenshot functionality in Firefox. This vulnerability affects Firefox &lt; 127.(CVE-2024-5697)A race condition could lead to a cross-origin container obtaining permissions of the top-level origin. This vulnerability affects Firefox &lt; 128, Firefox ESR &lt; 115.13, Thunderbird &lt; 115.13, and Thunderbird &lt; 128.(CVE-2024-6601)A mismatch between allocator and deallocator could have led to memory corruption. This vulnerability affects Firefox &lt; 128, Firefox ESR &lt; 115.13, Thunderbird &lt; 115.13, and Thunderbird &lt; 128.(CVE-2024-6602)In an out-of-memory scenario an allocation could fail but free would have been called on the pointer afterwards leading to memory corruption. This vulnerability affects Firefox &lt; 128, Firefox ESR &lt; 115.13, Thunderbird &lt; 115.13, and Thunderbird &lt; 128.(CVE-2024-6603)Memory safety bugs present in Firefox 127, Firefox ESR 115.12, and Thunderbird 115.12. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 128, Firefox ESR &lt; 115.13, Thunderbird &lt; 115.13, and Thunderbird &lt; 128.(CVE-2024-6604)Firefox Android allowed immediate interaction with permission prompts. This could be used for tapjacking. This vulnerability affects Firefox &lt; 128.(CVE-2024-6605)Clipboard code failed to check the index on an array access. This could have led to an out-of-bounds read. This vulnerability affects Firefox &lt; 128 and Thunderbird &lt; 128.(CVE-2024-6606)It was possible to prevent a user from exiting pointerlock when pressing escape and to overlay customValidity notifications from a `&lt;select&gt;` element over certain permission prompts. This could be used to confuse a user into giving a site unintended permissions. This vulnerability affects Firefox &lt; 128 and Thunderbird &lt; 128.(CVE-2024-6607)It was possible to move the cursor using pointerlock from an iframe. This allowed moving the cursor outside of the viewport and the Firefox window. This vulnerability affects Firefox &lt; 128 and Thunderbird &lt; 128.(CVE-2024-6608)When almost out-of-memory an elliptic curve key which was never allocated could have been freed again. This vulnerability affects Firefox &lt; 128 and Thunderbird &lt; 128.(CVE-2024-6609)Form validation popups could capture escape key presses. Therefore, spamming form validation messages could be used to prevent users from exiting full-screen mode. This vulnerability affects Firefox &lt; 128 and Thunderbird &lt; 128.(CVE-2024-6610)A nested iframe, triggering a cross-site navigation, could send SameSite=Strict or Lax cookies. This vulnerability affects Firefox &lt; 128 and Thunderbird &lt; 128.(CVE-2024-6611)CSP violations generated links in the console tab of the developer tools, pointing to the violating resource. This caused a DNS prefetch which leaked that a CSP violation happened. This vulnerability affects Firefox &lt; 128 and Thunderbird &lt; 128.(CVE-2024-6612)The frame iterator could get stuck in a loop when encountering certain wasm frames leading to incorrect stack traces. This vulnerability affects Firefox &lt; 128 and Thunderbird &lt; 128.(CVE-2024-6613)The frame iterator could get stuck in a loop when encountering certain wasm frames leading to incorrect stack traces. This vulnerability affects Firefox &lt; 128 and Thunderbird &lt; 128.(CVE-2024-6614)Memory safety bugs present in Firefox 127 and Thunderbird 127. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 128 and Thunderbird &lt; 128.(CVE-2024-6615)Insufficient checks when processing graphics shared memory could have led to memory corruption. This could be leveraged by an attacker to perform a sandbox escape. This vulnerability affects Firefox &lt; 129, Firefox ESR &lt; 115.14, Firefox ESR &lt; 128.1, Thunderbird &lt; 128.1, and Thunderbird &lt; 115.14.(CVE-2024-7519)Incomplete WebAssembly exception handing could have led to a use-after-free. This vulnerability affects Firefox &lt; 129, Firefox ESR &lt; 115.14, Firefox ESR &lt; 128.1, Thunderbird &lt; 128.1, and Thunderbird &lt; 115.14.(CVE-2024-7521)Editor code failed to check an attribute value. This could have led to an out-of-bounds read. This vulnerability affects Firefox &lt; 129, Firefox ESR &lt; 115.14, Firefox ESR &lt; 128.1, Thunderbird &lt; 128.1, and Thunderbird &lt; 115.14.(CVE-2024-7522)Firefox adds web-compatibility shims in place of some tracking scripts blocked by Enhanced Tracking Protection.  On a site protected by Content Security Policy in &#34;strict-dynamic&#34; mode, an attacker able to inject an HTML element could have used a DOM Clobbering attack on some of the shims and achieved XSS, bypassing the CSP strict-dynamic protection. This vulnerability affects Firefox &lt; 129, Firefox ESR &lt; 115.14, and Firefox ESR &lt; 128.1.(CVE-2024-7524)It was possible for a web extension with minimal permissions to create a `StreamFilter` which could be used to read and modify the response body of requests on any site. This vulnerability affects Firefox &lt; 129, Firefox ESR &lt; 115.14, Firefox ESR &lt; 128.1, Thunderbird &lt; 128.1, and Thunderbird &lt; 115.14.(CVE-2024-7525)ANGLE failed to initialize parameters which lead to reading from uninitialized memory. This could be leveraged to leak sensitive data from memory. This vulnerability affects Firefox &lt; 129, Firefox ESR &lt; 115.14, Firefox ESR &lt; 128.1, Thunderbird &lt; 128.1, and Thunderbird &lt; 115.14.(CVE-2024-7526)Unexpected marking work at the start of sweeping could have led to a use-after-free. This vulnerability affects Firefox &lt; 129, Firefox ESR &lt; 115.14, Firefox ESR &lt; 128.1, Thunderbird &lt; 128.1, and Thunderbird &lt; 115.14.(CVE-2024-7527)The date picker could partially obscure security prompts. This could be used by a malicious site to trick a user into granting permissions. This vulnerability affects Firefox &lt; 129, Firefox ESR &lt; 115.14, Firefox ESR &lt; 128.1, Thunderbird &lt; 128.1, and Thunderbird &lt; 115.14.(CVE-2024-7529)Calling `PK11_Encrypt()` in NSS using CKM_CHACHA20 and the same buffer for input and output can result in plaintext on an Intel Sandy Bridge processor. In Firefox this only affects the QUIC header protection feature when the connection is using the ChaCha20-Poly1305 cipher suite. The most likely outcome is connection failure, but if the connection persists despite the high packet loss it could be possible for a network observer to identify packets as coming from the same source despite a network path change. This vulnerability affects Firefox &lt; 129, Firefox ESR &lt; 115.14, and Firefox ESR &lt; 128.1.(CVE-2024-7531)An error in the ECMA-262 specification relating to Async Generators could have resulted in a type confusion, potentially leading to memory corruption and an exploitable crash. This vulnerability affects Firefox &lt; 128, Firefox ESR &lt; 115.13, Thunderbird &lt; 115.13, and Thunderbird &lt; 128.(CVE-2024-7652)A potentially exploitable type confusion could be triggered when looking up a property name on an object being used as the `with` environment. This vulnerability affects Firefox &lt; 130, Firefox ESR &lt; 128.2, Firefox ESR &lt; 115.15, Thunderbird &lt; 128.2, and Thunderbird &lt; 115.15.(CVE-2024-8381)Internal browser event interfaces were exposed to web content when privileged EventHandler listener callbacks ran for those events. Web content that tried to use those interfaces would not be able to use them with elevated privileges, but their presence would indicate certain browser features had been used, such as when a user opened the Dev Tools console. This vulnerability affects Firefox &lt; 130, Firefox ESR &lt; 128.2, Firefox ESR &lt; 115.15, Thunderbird &lt; 128.2, and Thunderbird &lt; 115.15.(CVE-2024-8382)Firefox normally asks for confirmation before asking the operating system to find an application to handle a scheme that the browser does not support. It did not ask before doing so for the Usenet-related schemes news: and snews:. Since most operating systems don&#39;t have a trusted newsreader installed by default, an unscrupulous program that the user downloaded could register itself as a handler. The website that served the application download could then launch that application at will. This vulnerability affects Firefox &lt; 130, Firefox ESR &lt; 128.2, and Firefox ESR &lt; 115.15.(CVE-2024-8383)The JavaScript garbage collector could mis-color cross-compartment objects if OOM conditions were detected at the right point between two passes. This could have led to memory corruption. This vulnerability affects Firefox &lt; 130, Firefox ESR &lt; 128.2, Firefox ESR &lt; 115.15, Thunderbird &lt; 128.2, and Thunderbird &lt; 115.15.(CVE-2024-8384)A compromised content process could have allowed for the arbitrary loading of cross-origin pages. This vulnerability affects Firefox &lt; 131, Firefox ESR &lt; 128.3, Firefox ESR &lt; 115.16, Thunderbird &lt; 128.3, and Thunderbird &lt; 131.(CVE-2024-9392)An attacker could, via a specially crafted multipart response, execute arbitrary JavaScript under the `resource://pdf.js` origin.  This could allow them to access cross-origin PDF content. This access is limited to &#34;same site&#34; documents by the Site Isolation feature on desktop clients, but full cross-origin access is possible on Android versions. This vulnerability affects Firefox &lt; 131, Firefox ESR &lt; 128.3, Firefox ESR &lt; 115.16, Thunderbird &lt; 128.3, and Thunderbird &lt; 131.(CVE-2024-9393)An attacker could, via a specially crafted multipart response, execute arbitrary JavaScript under the `resource://devtools` origin.  This could allow them to access cross-origin JSON content. This access is limited to &#34;same site&#34; documents by the Site Isolation feature on desktop clients, but full cross-origin access is possible on Android versions. This vulnerability affects Firefox &lt; 131, Firefox ESR &lt; 128.3, Firefox ESR &lt; 115.16, Thunderbird &lt; 128.3, and Thunderbird &lt; 131.(CVE-2024-9394)It is currently unknown if this issue is exploitable but a condition may arise where the structured clone of certain objects could lead to memory corruption. This vulnerability affects Firefox &lt; 131, Firefox ESR &lt; 128.3, Thunderbird &lt; 128.3, and Thunderbird &lt; 131.(CVE-2024-9396)A missing delay in directory upload UI could have made it possible for an attacker to trick a user into granting permission via clickjacking. This vulnerability affects Firefox &lt; 131, Firefox ESR &lt; 128.3, Thunderbird &lt; 128.3, and Thunderbird &lt; 131.(CVE-2024-9397)By checking the result of calls to `window.open` with specifically set protocol handlers, an attacker could determine if the application which implements that protocol handler is installed. This vulnerability affects Firefox &lt; 131, Firefox ESR &lt; 128.3, Thunderbird &lt; 128.3, and Thunderbird &lt; 131.(CVE-2024-9398)A website configured to initiate a specially crafted WebTransport session could crash the Firefox process leading to a denial of service condition. This vulnerability affects Firefox &lt; 131, Firefox ESR &lt; 128.3, Thunderbird &lt; 128.3, and Thunderbird &lt; 131.(CVE-2024-9399)A potential memory corruption vulnerability could be triggered if an attacker had the ability to trigger an OOM at a specific moment during JIT compilation. This vulnerability affects Firefox &lt; 131, Firefox ESR &lt; 128.3, Thunderbird &lt; 128.3, and Thunderbird &lt; 131.(CVE-2024-9400)Memory safety bugs present in Firefox 130, Firefox ESR 115.15, Firefox ESR 128.2, and Thunderbird 128.2. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 131, Firefox ESR &lt; 128.3, Firefox ESR &lt; 115.16, Thunderbird &lt; 128.3, and Thunderbird &lt; 131.(CVE-2024-9401)Memory safety bugs present in Firefox 130, Firefox ESR 128.2, and Thunderbird 128.2. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 131, Firefox ESR &lt; 128.3, Thunderbird &lt; 128.3, and Thunderbird &lt; 131.(CVE-2024-9402)An attacker was able to achieve code execution in the content process by exploiting a use-after-free in Animation timelines. We have had reports of this vulnerability being exploited in the wild. This vulnerability affects Firefox &lt; 131.0.2, Firefox ESR &lt; 128.3.1, Firefox ESR &lt; 115.16.1, Thunderbird &lt; 131.0.1, Thunderbird &lt; 128.3.1, and Thunderbird &lt; 115.16.0.(CVE-2024-9680)It was possible to cause a use-after-free in the content process side of a WebTransport connection, leading to a potentially exploitable crash. This vulnerability affects Firefox &lt; 136, Firefox ESR &lt; 115.21, Firefox ESR &lt; 128.8, Thunderbird &lt; 136, and Thunderbird &lt; 128.8.(CVE-2025-1931)An inconsistent comparator in xslt/txNodeSorter could have resulted in potentially exploitable out-of-bounds access. Only affected version 122 and later. This vulnerability affects Firefox &lt; 136, Firefox ESR &lt; 128.8, Thunderbird &lt; 136, and Thunderbird &lt; 128.8.(CVE-2025-1932)On 64-bit CPUs, when the JIT compiles WASM i32 return values they can pick up bits from left over memory. This can potentially cause them to be treated as a different type. This vulnerability affects Firefox &lt; 136, Firefox ESR &lt; 115.21, Firefox ESR &lt; 128.8, Thunderbird &lt; 136, and Thunderbird &lt; 128.8.(CVE-2025-1933)It was possible to interrupt the processing of a RegExp bailout and run additional JavaScript, potentially triggering garbage collection when the engine was not expecting it. This vulnerability affects Firefox &lt; 136, Firefox ESR &lt; 128.8, Thunderbird &lt; 136, and Thunderbird &lt; 128.8.(CVE-2025-1934)A web page could trick a user into setting that site as the default handler for a custom URL protocol. This vulnerability affects Firefox &lt; 136, Firefox ESR &lt; 128.8, Thunderbird &lt; 136, and Thunderbird &lt; 128.8.(CVE-2025-1935)jar: URLs retrieve local file content packaged in a ZIP archive. The null and everything after it was ignored when retrieving the content from the archive, but the fake extension after the null was used to determine the type of content. This could have been used to hide code in a web extension disguised as something else like an image. This vulnerability affects Firefox &lt; 136, Firefox ESR &lt; 128.8, Thunderbird &lt; 136, and Thunderbird &lt; 128.8.(CVE-2025-1936)Memory safety bugs present in Firefox 135, Thunderbird 135, Firefox ESR 115.20, Firefox ESR 128.7, and Thunderbird 128.7. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 136, Firefox ESR &lt; 115.21, Firefox ESR &lt; 128.8, Thunderbird &lt; 136, and Thunderbird &lt; 128.8.(CVE-2025-1937)Memory safety bugs present in Firefox 135, Thunderbird 135, Firefox ESR 128.7, and Thunderbird 128.7. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 136, Firefox ESR &lt; 128.8, Thunderbird &lt; 136, and Thunderbird &lt; 128.8.(CVE-2025-1938)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="firefox" release="1.oe2203sp4" version="128.8.0">
                         <filename>firefox-128.8.0-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="firefox-debuginfo" release="1.oe2203sp4" version="128.8.0">
                         <filename>firefox-debuginfo-128.8.0-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="firefox-debugsource" release="1.oe2203sp4" version="128.8.0">
                         <filename>firefox-debugsource-128.8.0-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox" release="1.oe2203sp4" version="128.8.0">
                         <filename>firefox-128.8.0-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox-debuginfo" release="1.oe2203sp4" version="128.8.0">
                         <filename>firefox-debuginfo-128.8.0-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox-debugsource" release="1.oe2203sp4" version="128.8.0">
                         <filename>firefox-debugsource-128.8.0-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1270</id>
          <title>An update for pki-core is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-03-14"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4727" id="CVE-2023-4727" title="CVE-2023-4727" type="cve"></reference>
          </references>
          <description>A flaw was found in dogtag-pki and pki-core. The token authentication scheme can be bypassed with a LDAP injection. By passing the query string parameter sessionID=*, an attacker can authenticate with an existing session saved in the LDAP directory server, which may lead to escalation of privilege.(CVE-2023-4727)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="pki-core-debuginfo" release="6.oe2203sp4" version="11.0.0">
                         <filename>pki-core-debuginfo-11.0.0-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pki-core-debugsource" release="6.oe2203sp4" version="11.0.0">
                         <filename>pki-core-debugsource-11.0.0-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pki-symkey" release="6.oe2203sp4" version="11.0.0">
                         <filename>pki-symkey-11.0.0-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pki-tools" release="6.oe2203sp4" version="11.0.0">
                         <filename>pki-tools-11.0.0-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pki-tps" release="6.oe2203sp4" version="11.0.0">
                         <filename>pki-tps-11.0.0-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="pki-base" release="6.oe2203sp4" version="11.0.0">
                         <filename>pki-base-11.0.0-6.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="pki-base-java" release="6.oe2203sp4" version="11.0.0">
                         <filename>pki-base-java-11.0.0-6.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="pki-ca" release="6.oe2203sp4" version="11.0.0">
                         <filename>pki-ca-11.0.0-6.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="pki-help" release="6.oe2203sp4" version="11.0.0">
                         <filename>pki-help-11.0.0-6.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="pki-kra" release="6.oe2203sp4" version="11.0.0">
                         <filename>pki-kra-11.0.0-6.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="pki-ocsp" release="6.oe2203sp4" version="11.0.0">
                         <filename>pki-ocsp-11.0.0-6.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="pki-server" release="6.oe2203sp4" version="11.0.0">
                         <filename>pki-server-11.0.0-6.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="pki-tks" release="6.oe2203sp4" version="11.0.0">
                         <filename>pki-tks-11.0.0-6.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-pki" release="6.oe2203sp4" version="11.0.0">
                         <filename>python3-pki-11.0.0-6.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pki-core-debuginfo" release="6.oe2203sp4" version="11.0.0">
                         <filename>pki-core-debuginfo-11.0.0-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pki-core-debugsource" release="6.oe2203sp4" version="11.0.0">
                         <filename>pki-core-debugsource-11.0.0-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pki-symkey" release="6.oe2203sp4" version="11.0.0">
                         <filename>pki-symkey-11.0.0-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pki-tools" release="6.oe2203sp4" version="11.0.0">
                         <filename>pki-tools-11.0.0-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pki-tps" release="6.oe2203sp4" version="11.0.0">
                         <filename>pki-tps-11.0.0-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1271</id>
          <title>An update for python-aiohttp is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-03-14"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-23334" id="CVE-2024-23334" title="CVE-2024-23334" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27306" id="CVE-2024-27306" title="CVE-2024-27306" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-30251" id="CVE-2024-30251" title="CVE-2024-30251" type="cve"></reference>
          </references>
          <description>aiohttp is an asynchronous HTTP client/server framework for asyncio and Python. When using aiohttp as a web server and configuring static routes, it is necessary to specify the root path for static files. Additionally, the option &#39;follow_symlinks&#39; can be used to determine whether to follow symbolic links outside the static root directory. When &#39;follow_symlinks&#39; is set to True, there is no validation to check if reading a file is within the root directory. This can lead to directory traversal vulnerabilities, resulting in unauthorized access to arbitrary files on the system, even when symlinks are not present.  Disabling follow_symlinks and using a reverse proxy are encouraged mitigations.  Version 3.9.2 fixes this issue.(CVE-2024-23334)aiohttp is an asynchronous HTTP client/server framework for asyncio and Python. A XSS vulnerability exists on index pages for static file handling. This vulnerability is fixed in 3.9.4. We have always recommended using a reverse proxy server (e.g. nginx) for serving static files. Users following the recommendation are unaffected. Other users can disable `show_index` if unable to upgrade.(CVE-2024-27306)aiohttp is an asynchronous HTTP client/server framework for asyncio and Python. In affected versions an attacker can send a specially crafted POST (multipart/form-data) request. When the aiohttp server processes it, the server will enter an infinite loop and be unable to process any further requests. An attacker can stop the application from serving requests after sending a single request. This issue has been addressed in version 3.9.4. Users are advised to upgrade. Users unable to upgrade may manually apply a patch to their systems. Please see the linked GHSA for instructions.(CVE-2024-30251)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="python-aiohttp-debuginfo" release="6.oe2203sp4" version="3.7.4">
                         <filename>python-aiohttp-debuginfo-3.7.4-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python-aiohttp-debugsource" release="6.oe2203sp4" version="3.7.4">
                         <filename>python-aiohttp-debugsource-3.7.4-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python-aiohttp-help" release="6.oe2203sp4" version="3.7.4">
                         <filename>python-aiohttp-help-3.7.4-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-aiohttp" release="6.oe2203sp4" version="3.7.4">
                         <filename>python3-aiohttp-3.7.4-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python-aiohttp-debuginfo" release="6.oe2203sp4" version="3.7.4">
                         <filename>python-aiohttp-debuginfo-3.7.4-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python-aiohttp-debugsource" release="6.oe2203sp4" version="3.7.4">
                         <filename>python-aiohttp-debugsource-3.7.4-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python-aiohttp-help" release="6.oe2203sp4" version="3.7.4">
                         <filename>python-aiohttp-help-3.7.4-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-aiohttp" release="6.oe2203sp4" version="3.7.4">
                         <filename>python3-aiohttp-3.7.4-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1274</id>
          <title>An update for nodejs is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-03-14"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-23085" id="CVE-2025-23085" title="CVE-2025-23085" type="cve"></reference>
          </references>
          <description>A memory leak could occur when a remote peer abruptly closes the socket without sending a GOAWAY notification. Additionally, if an invalid header was detected by nghttp2, causing the connection to be terminated by the peer, the same leak was triggered. This flaw could lead to increased memory consumption and potential denial of service under certain conditions.This vulnerability affects HTTP/2 Server users on Node.js v18.x, v20.x, v22.x and v23.x.(CVE-2025-23085)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="nodejs" release="11.oe2203sp4" version="12.22.11">
                         <filename>nodejs-12.22.11-11.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nodejs-debuginfo" release="11.oe2203sp4" version="12.22.11">
                         <filename>nodejs-debuginfo-12.22.11-11.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nodejs-debugsource" release="11.oe2203sp4" version="12.22.11">
                         <filename>nodejs-debugsource-12.22.11-11.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nodejs-devel" release="11.oe2203sp4" version="12.22.11">
                         <filename>nodejs-devel-12.22.11-11.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nodejs-full-i18n" release="11.oe2203sp4" version="12.22.11">
                         <filename>nodejs-full-i18n-12.22.11-11.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nodejs-libs" release="11.oe2203sp4" version="12.22.11">
                         <filename>nodejs-libs-12.22.11-11.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="npm" release="1.12.22.11.11.oe2203sp4" version="6.14.16">
                         <filename>npm-6.14.16-1.12.22.11.11.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="v8-devel" release="1.12.22.11.11.oe2203sp4" version="7.8.279.23">
                         <filename>v8-devel-7.8.279.23-1.12.22.11.11.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="nodejs-docs" release="11.oe2203sp4" version="12.22.11">
                         <filename>nodejs-docs-12.22.11-11.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nodejs" release="11.oe2203sp4" version="12.22.11">
                         <filename>nodejs-12.22.11-11.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nodejs-debuginfo" release="11.oe2203sp4" version="12.22.11">
                         <filename>nodejs-debuginfo-12.22.11-11.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nodejs-debugsource" release="11.oe2203sp4" version="12.22.11">
                         <filename>nodejs-debugsource-12.22.11-11.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nodejs-devel" release="11.oe2203sp4" version="12.22.11">
                         <filename>nodejs-devel-12.22.11-11.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nodejs-full-i18n" release="11.oe2203sp4" version="12.22.11">
                         <filename>nodejs-full-i18n-12.22.11-11.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nodejs-libs" release="11.oe2203sp4" version="12.22.11">
                         <filename>nodejs-libs-12.22.11-11.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="npm" release="1.12.22.11.11.oe2203sp4" version="6.14.16">
                         <filename>npm-6.14.16-1.12.22.11.11.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="v8-devel" release="1.12.22.11.11.oe2203sp4" version="7.8.279.23">
                         <filename>v8-devel-7.8.279.23-1.12.22.11.11.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1277</id>
          <title>An update for iniparser is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-03-14"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-0633" id="CVE-2025-0633" title="CVE-2025-0633" type="cve"></reference>
          </references>
          <description>Heap-based Buffer Overflow vulnerability in iniparser_dumpsection_ini() in iniparser allows attacker to read out of bound memory(CVE-2025-0633)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="iniparser" release="6.oe2203sp4" version="4.1">
                         <filename>iniparser-4.1-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="iniparser-debuginfo" release="6.oe2203sp4" version="4.1">
                         <filename>iniparser-debuginfo-4.1-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="iniparser-debugsource" release="6.oe2203sp4" version="4.1">
                         <filename>iniparser-debugsource-4.1-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="iniparser" release="6.oe2203sp4" version="4.1">
                         <filename>iniparser-4.1-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="iniparser-debuginfo" release="6.oe2203sp4" version="4.1">
                         <filename>iniparser-debuginfo-4.1-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="iniparser-debugsource" release="6.oe2203sp4" version="4.1">
                         <filename>iniparser-debugsource-4.1-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1279</id>
          <title>An update for syslinux is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-03-14"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-24370" id="CVE-2020-24370" title="CVE-2020-24370" type="cve"></reference>
          </references>
          <description>ldebug.c in Lua 5.4.0 allows a negation overflow and segmentation fault in getlocal and setlocal, as demonstrated by getlocal(3,2^31).(CVE-2020-24370)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="syslinux-extlinux-nonlinux" release="17.oe2203sp4" version="6.04">
                         <filename>syslinux-extlinux-nonlinux-6.04-17.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="syslinux-nonlinux" release="17.oe2203sp4" version="6.04">
                         <filename>syslinux-nonlinux-6.04-17.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="syslinux-tftpboot" release="17.oe2203sp4" version="6.04">
                         <filename>syslinux-tftpboot-6.04-17.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="syslinux" release="17.oe2203sp4" version="6.04">
                         <filename>syslinux-6.04-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="syslinux-debuginfo" release="17.oe2203sp4" version="6.04">
                         <filename>syslinux-debuginfo-6.04-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="syslinux-debugsource" release="17.oe2203sp4" version="6.04">
                         <filename>syslinux-debugsource-6.04-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="syslinux-devel" release="17.oe2203sp4" version="6.04">
                         <filename>syslinux-devel-6.04-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="syslinux-efi64" release="17.oe2203sp4" version="6.04">
                         <filename>syslinux-efi64-6.04-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="syslinux-extlinux" release="17.oe2203sp4" version="6.04">
                         <filename>syslinux-extlinux-6.04-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="syslinux-perl" release="17.oe2203sp4" version="6.04">
                         <filename>syslinux-perl-6.04-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1284</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-03-14"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49096" id="CVE-2022-49096" title="CVE-2022-49096" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49564" id="CVE-2022-49564" title="CVE-2022-49564" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49651" id="CVE-2022-49651" title="CVE-2022-49651" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-54680" id="CVE-2024-54680" title="CVE-2024-54680" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56723" id="CVE-2024-56723" title="CVE-2024-56723" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57947" id="CVE-2024-57947" title="CVE-2024-57947" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-58001" id="CVE-2024-58001" title="CVE-2024-58001" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-58009" id="CVE-2024-58009" title="CVE-2024-58009" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21719" id="CVE-2025-21719" title="CVE-2025-21719" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21735" id="CVE-2025-21735" title="CVE-2025-21735" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21756" id="CVE-2025-21756" title="CVE-2025-21756" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21779" id="CVE-2025-21779" title="CVE-2025-21779" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21782" id="CVE-2025-21782" title="CVE-2025-21782" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:net: sfc: add missing xdp queue reinitializationAfter rx/tx ring buffer size is changed, kernel panic occurs whenit acts XDP_TX or XDP_REDIRECT.When tx/rx ring buffer size is changed(ethtool -G), sfc driverreallocates and reinitializes rx and tx queues and their buffer(tx_queue-&gt;buffer).But it misses reinitializing xdp queues(efx-&gt;xdp_tx_queues).So, while it is acting XDP_TX or XDP_REDIRECT, it uses the uninitializedtx_queue-&gt;buffer.A new function efx_set_xdp_channels() is separated from efx_set_channels()to handle only xdp queues.Splat looks like:   BUG: kernel NULL pointer dereference, address: 000000000000002a   #PF: supervisor write access in kernel mode   #PF: error_code(0x0002) - not-present page   PGD 0 P4D 0   Oops: 0002 [#4] PREEMPT SMP NOPTI   RIP: 0010:efx_tx_map_chunk+0x54/0x90 [sfc]   CPU: 2 PID: 0 Comm: swapper/2 Tainted: G      D           5.17.0+ #55 e8beeee8289528f11357029357cf   Code: 48 8b 8d a8 01 00 00 48 8d 14 52 4c 8d 2c d0 44 89 e0 48 85 c9 74 0e 44 89 e2 4c 89 f6 48 80   RSP: 0018:ffff92f121e45c60 EFLAGS: 00010297   RIP: 0010:efx_tx_map_chunk+0x54/0x90 [sfc]   RAX: 0000000000000040 RBX: ffff92ea506895c0 RCX: ffffffffc0330870   RDX: 0000000000000001 RSI: 00000001139b10ce RDI: ffff92ea506895c0   RBP: ffffffffc0358a80 R08: 00000001139b110d R09: 0000000000000000   R10: 0000000000000001 R11: ffff92ea414c0088 R12: 0000000000000040   R13: 0000000000000018 R14: 00000001139b10ce R15: ffff92ea506895c0   FS:  0000000000000000(0000) GS:ffff92f121ec0000(0000) knlGS:0000000000000000   CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033   Code: 48 8b 8d a8 01 00 00 48 8d 14 52 4c 8d 2c d0 44 89 e0 48 85 c9 74 0e 44 89 e2 4c 89 f6 48 80   CR2: 000000000000002a CR3: 00000003e6810004 CR4: 00000000007706e0   RSP: 0018:ffff92f121e85c60 EFLAGS: 00010297   PKRU: 55555554   RAX: 0000000000000040 RBX: ffff92ea50689700 RCX: ffffffffc0330870   RDX: 0000000000000001 RSI: 00000001145a90ce RDI: ffff92ea50689700   RBP: ffffffffc0358a80 R08: 00000001145a910d R09: 0000000000000000   R10: 0000000000000001 R11: ffff92ea414c0088 R12: 0000000000000040   R13: 0000000000000018 R14: 00000001145a90ce R15: ffff92ea50689700   FS:  0000000000000000(0000) GS:ffff92f121e80000(0000) knlGS:0000000000000000   CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033   CR2: 000000000000002a CR3: 00000003e6810005 CR4: 00000000007706e0   PKRU: 55555554   Call Trace:    &lt;IRQ&gt;    efx_xdp_tx_buffers+0x12b/0x3d0 [sfc 84c94b8e32d44d296c17e10a634d3ad454de4ba5]    __efx_rx_packet+0x5c3/0x930 [sfc 84c94b8e32d44d296c17e10a634d3ad454de4ba5]    efx_rx_packet+0x28c/0x2e0 [sfc 84c94b8e32d44d296c17e10a634d3ad454de4ba5]    efx_ef10_ev_process+0x5f8/0xf40 [sfc 84c94b8e32d44d296c17e10a634d3ad454de4ba5]    ? enqueue_task_fair+0x95/0x550    efx_poll+0xc4/0x360 [sfc 84c94b8e32d44d296c17e10a634d3ad454de4ba5](CVE-2022-49096)In the Linux kernel, the following vulnerability has been resolved:crypto: qat - add param check for DHReject requests with a source buffer that is bigger than the size of thekey. This is to prevent a possible integer underflow that might happenwhen copying the source scatterlist into a linear buffer.(CVE-2022-49564)In the Linux kernel, the following vulnerability has been resolved:srcu: Tighten cleanup_srcu_struct() GP checksCurrently, cleanup_srcu_struct() checks for a grace period in progress,but it does not check for a grace period that has not yet started butwhich might start at any time.  Such a situation could result in ause-after-free bug, so this commit adds a check for a grace period thatis needed but not yet started to cleanup_srcu_struct().(CVE-2022-49651)In the Linux kernel, the following vulnerability has been resolved:smb: client: fix TCP timers deadlock after rmmodCommit ef7134c7fc48 (&#34;smb: client: Fix use-after-free of network namespace.&#34;)fixed a netns UAF by manually enabled socket refcounting(sk-&gt;sk_net_refcnt=1 and sock_inuse_add(net, 1)).The reason the patch worked for that bug was because we now holdreferences to the netns (get_net_track() gets a ref internally)and they&#39;re properly released (internally, on __sk_destruct()),but only because sk-&gt;sk_net_refcnt was set.Problem:(this happens regardless of CONFIG_NET_NS_REFCNT_TRACKER and regardlessif init_net or other)Setting sk-&gt;sk_net_refcnt=1 *manually* and *after* socket creation is notonly out of cifs scope, but also technically wrong -- it&#39;s set conditionallybased on user (=1) vs kernel (=0) sockets.  And net/ implementationsseem to base their user vs kernel space operations on it.e.g. upon TCP socket close, the TCP timers are not cleared becausesk-&gt;sk_net_refcnt=1:(cf. commit 151c9c724d05 (&#34;tcp: properly terminate timers for kernel sockets&#34;))net/ipv4/tcp.c:    void tcp_close(struct sock *sk, long timeout)    {    &#x9;lock_sock(sk);    &#x9;__tcp_close(sk, timeout);    &#x9;release_sock(sk);    &#x9;if (!sk-&gt;sk_net_refcnt)    &#x9;&#x9;inet_csk_clear_xmit_timers_sync(sk);    &#x9;sock_put(sk);    }Which will throw a lockdep warning and then, as expected, deadlock ontcp_write_timer().A way to reproduce this is by running the reproducer from ef7134c7fc48and then &#39;rmmod cifs&#39;.  A few seconds later, the deadlock/lockdepwarning shows up.Fix:We shouldn&#39;t mess with socket internals ourselves, so do not setsk_net_refcnt manually.Also change __sock_create() to sock_create_kern() for explicitness.As for non-init_net network namespaces, we deal with it the best waywe can -- hold an extra netns reference for server-&gt;ssocket and drop itwhen it&#39;s released.  This ensures that the netns still exists wheneverwe need to create/destroy server-&gt;ssocket, but is not directly tied toit.(CVE-2024-54680)In the Linux kernel, the following vulnerability has been resolved:mfd: intel_soc_pmic_bxtwc: Use IRQ domain for PMIC devicesWhile design wise the idea of converting the driver to usethe hierarchy of the IRQ chips is correct, the implementationhas (inherited) flaws. This was unveiled when platform_get_irq()had started WARN() on IRQ 0 that is supposed to be a LinuxIRQ number (also known as vIRQ).Rework the driver to respect IRQ domain when creating each MFDdevice separately, as the domain is not the same for all of them.(CVE-2024-56723)In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_set_pipapo: fix initial map fillThe initial buffer has to be inited to all-ones, but it must restrictit to the size of the first field, not the total field size.After each round in the map search step, the result and the fill mapare swapped, so if we have a set where f-&gt;bsize of the first elementis smaller than m-&gt;bsize_max, those one-bits are leaked into futurerounds result map.This makes pipapo find an incorrect matching results for sets wherefirst field size is not the largest.Followup patch adds a test case to nft_concat_range.sh selftest script.Thanks to Stefano Brivio for pointing out that we need to zero outthe remainder explicitly, only correcting memset() argument isn&#39;t enough.(CVE-2024-57947)In the Linux kernel, the following vulnerability has been resolved:ocfs2: handle a symlink read error correctlyPatch series &#34;Convert ocfs2 to use folios&#34;.Mark did a conversion of ocfs2 to use folios and sent it to me as agiant patch for review ;-)So I&#39;ve redone it as individual patches, and credited Mark for the patcheswhere his code is substantially the same.  It&#39;s not a bad way to do it;his patch had some bugs and my patches had some bugs.  Hopefully all ourbugs were different from each other.  And hopefully Mark likes all thechanges I made to his code!This patch (of 23):If we can&#39;t read the buffer, be sure to unlock the page before returning.(CVE-2024-58001)In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: handle NULL sock pointer in l2cap_sock_allocA NULL sock pointer is passed into l2cap_sock_alloc() when it is calledfrom l2cap_sock_new_connection_cb() and the error handling paths shouldalso be aware of it.Seemingly a more elegant solution would be to swap bt_sock_alloc() andl2cap_chan_create() calls since they are not interdependent to that momentbut then l2cap_chan_create() adds the soon to be deallocated and stilldummy-initialized channel to the global list accessible by many L2CAPpaths. The channel would be removed from the list in short period of timebut be a bit more straight-forward here and just check for NULL instead ofchanging the order of function calls.Found by Linux Verification Center (linuxtesting.org) with SVACE staticanalysis tool.(CVE-2024-58009)In the Linux kernel, the following vulnerability has been resolved:ipmr: do not call mr_mfc_uses_dev() for unres entriessyzbot found that calling mr_mfc_uses_dev() for unres entrieswould crash [1], because c-&gt;mfc_un.res.minvif / c-&gt;mfc_un.res.maxvifalias to &#34;struct sk_buff_head unresolved&#34;, which contain two pointers.This code never worked, lets remove it.[1]Unable to handle kernel paging request at virtual address ffff5fff2d536613KASAN: maybe wild-memory-access in range [0xfffefff96a9b3098-0xfffefff96a9b309f]Modules linked in:CPU: 1 UID: 0 PID: 7321 Comm: syz.0.16 Not tainted 6.13.0-rc7-syzkaller-g1950a0af2d55 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mr_mfc_uses_dev net/ipv4/ipmr_base.c:290 [inline] pc : mr_table_dump+0x5a4/0x8b0 net/ipv4/ipmr_base.c:334 lr : mr_mfc_uses_dev net/ipv4/ipmr_base.c:289 [inline] lr : mr_table_dump+0x694/0x8b0 net/ipv4/ipmr_base.c:334Call trace:  mr_mfc_uses_dev net/ipv4/ipmr_base.c:290 [inline] (P)  mr_table_dump+0x5a4/0x8b0 net/ipv4/ipmr_base.c:334 (P)  mr_rtm_dumproute+0x254/0x454 net/ipv4/ipmr_base.c:382  ipmr_rtm_dumproute+0x248/0x4b4 net/ipv4/ipmr.c:2648  rtnl_dump_all+0x2e4/0x4e8 net/core/rtnetlink.c:4327  rtnl_dumpit+0x98/0x1d0 net/core/rtnetlink.c:6791  netlink_dump+0x4f0/0xbc0 net/netlink/af_netlink.c:2317  netlink_recvmsg+0x56c/0xe64 net/netlink/af_netlink.c:1973  sock_recvmsg_nosec net/socket.c:1033 [inline]  sock_recvmsg net/socket.c:1055 [inline]  sock_read_iter+0x2d8/0x40c net/socket.c:1125  new_sync_read fs/read_write.c:484 [inline]  vfs_read+0x740/0x970 fs/read_write.c:565  ksys_read+0x15c/0x26c fs/read_write.c:708(CVE-2025-21719)In the Linux kernel, the following vulnerability has been resolved:NFC: nci: Add bounds checking in nci_hci_create_pipe()The &#34;pipe&#34; variable is a u8 which comes from the network.  If it&#39;s morethan 127, then it results in memory corruption in the caller,nci_hci_connect_gate().(CVE-2025-21735)In the Linux kernel, the following vulnerability has been resolved:vsock: Keep the binding until socket destructionPreserve sockets bindings; this includes both resulting from an explicitbind() and those implicitly bound through autobind during connect().Prevents socket unbinding during a transport reassignment, which fixes ause-after-free:    1. vsock_create() (refcnt=1) calls vsock_insert_unbound() (refcnt=2)    2. transport-&gt;release() calls vsock_remove_bound() without checking if       sk was bound and moved to bound list (refcnt=1)    3. vsock_bind() assumes sk is in unbound list and before       __vsock_insert_bound(vsock_bound_sockets()) calls       __vsock_remove_bound() which does:           list_del_init(&amp;vsk-&gt;bound_table); // nop           sock_put(&amp;vsk-&gt;sk);               // refcnt=0BUG: KASAN: slab-use-after-free in __vsock_bind+0x62e/0x730Read of size 4 at addr ffff88816b46a74c by task a.out/2057 dump_stack_lvl+0x68/0x90 print_report+0x174/0x4f6 kasan_report+0xb9/0x190 __vsock_bind+0x62e/0x730 vsock_bind+0x97/0xe0 __sys_bind+0x154/0x1f0 __x64_sys_bind+0x6e/0xb0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7eAllocated by task 2057: kasan_save_stack+0x1e/0x40 kasan_save_track+0x10/0x30 __kasan_slab_alloc+0x85/0x90 kmem_cache_alloc_noprof+0x131/0x450 sk_prot_alloc+0x5b/0x220 sk_alloc+0x2c/0x870 __vsock_create.constprop.0+0x2e/0xb60 vsock_create+0xe4/0x420 __sock_create+0x241/0x650 __sys_socket+0xf2/0x1a0 __x64_sys_socket+0x6e/0xb0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7eFreed by task 2057: kasan_save_stack+0x1e/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x60 __kasan_slab_free+0x4b/0x70 kmem_cache_free+0x1a1/0x590 __sk_destruct+0x388/0x5a0 __vsock_bind+0x5e1/0x730 vsock_bind+0x97/0xe0 __sys_bind+0x154/0x1f0 __x64_sys_bind+0x6e/0xb0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7erefcount_t: addition on 0; use-after-free.WARNING: CPU: 7 PID: 2057 at lib/refcount.c:25 refcount_warn_saturate+0xce/0x150RIP: 0010:refcount_warn_saturate+0xce/0x150 __vsock_bind+0x66d/0x730 vsock_bind+0x97/0xe0 __sys_bind+0x154/0x1f0 __x64_sys_bind+0x6e/0xb0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7erefcount_t: underflow; use-after-free.WARNING: CPU: 7 PID: 2057 at lib/refcount.c:28 refcount_warn_saturate+0xee/0x150RIP: 0010:refcount_warn_saturate+0xee/0x150 vsock_remove_bound+0x187/0x1e0 __vsock_release+0x383/0x4a0 vsock_release+0x90/0x120 __sock_release+0xa3/0x250 sock_close+0x14/0x20 __fput+0x359/0xa80 task_work_run+0x107/0x1d0 do_exit+0x847/0x2560 do_group_exit+0xb8/0x250 __x64_sys_exit_group+0x3a/0x50 x64_sys_call+0xfec/0x14f0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2025-21756)In the Linux kernel, the following vulnerability has been resolved:KVM: x86: Reject Hyper-V&#39;s SEND_IPI hypercalls if local APIC isn&#39;t in-kernelAdvertise support for Hyper-V&#39;s SEND_IPI and SEND_IPI_EX hypercalls if andonly if the local API is emulated/virtualized by KVM, and explicitly rejectsaid hypercalls if the local APIC is emulated in userspace, i.e. don&#39;t relyon userspace to opt-in to KVM_CAP_HYPERV_ENFORCE_CPUID.Rejecting SEND_IPI and SEND_IPI_EX fixes a NULL-pointer dereference ifHyper-V enlightenments are exposed to the guest without an in-kernel localAPIC:  dump_stack+0xbe/0xfd  __kasan_report.cold+0x34/0x84  kasan_report+0x3a/0x50  __apic_accept_irq+0x3a/0x5c0  kvm_hv_send_ipi.isra.0+0x34e/0x820  kvm_hv_hypercall+0x8d9/0x9d0  kvm_emulate_hypercall+0x506/0x7e0  __vmx_handle_exit+0x283/0xb60  vmx_handle_exit+0x1d/0xd0  vcpu_enter_guest+0x16b0/0x24c0  vcpu_run+0xc0/0x550  kvm_arch_vcpu_ioctl_run+0x170/0x6d0  kvm_vcpu_ioctl+0x413/0xb20  __se_sys_ioctl+0x111/0x160  do_syscal1_64+0x30/0x40  entry_SYSCALL_64_after_hwframe+0x67/0xd1Note, checking the sending vCPU is sufficient, as the per-VM irqchip_modecan&#39;t be modified after vCPUs are created, i.e. if one vCPU has anin-kernel local APIC, then all vCPUs have an in-kernel local APIC.(CVE-2025-21779)In the Linux kernel, the following vulnerability has been resolved:orangefs: fix a oob in orangefs_debug_writeI got a syzbot report: slab-out-of-bounds Read inorangefs_debug_write... several people suggested fixes,I tested Al Viro&#39;s suggestion and made this patch.(CVE-2025-21782)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="bpftool" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-254.0.0.158.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-254.0.0.158.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-254.0.0.158.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-254.0.0.158.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-254.0.0.158.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-254.0.0.158.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-254.0.0.158.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-254.0.0.158.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-254.0.0.158.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-254.0.0.158.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-254.0.0.158.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-254.0.0.158.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-254.0.0.158.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-254.0.0.158.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-254.0.0.158.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-254.0.0.158.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-254.0.0.158.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-254.0.0.158.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-254.0.0.158.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-254.0.0.158.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-254.0.0.158.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-254.0.0.158.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-254.0.0.158.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-254.0.0.158.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-254.0.0.158.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-254.0.0.158.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-254.0.0.158.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-254.0.0.158.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-254.0.0.158.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-254.0.0.158.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1292</id>
          <title>An update for grub2 is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-03-14"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45775" id="CVE-2024-45775" title="CVE-2024-45775" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45776" id="CVE-2024-45776" title="CVE-2024-45776" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45777" id="CVE-2024-45777" title="CVE-2024-45777" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45781" id="CVE-2024-45781" title="CVE-2024-45781" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45782" id="CVE-2024-45782" title="CVE-2024-45782" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45783" id="CVE-2024-45783" title="CVE-2024-45783" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-0678" id="CVE-2025-0678" title="CVE-2025-0678" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-0684" id="CVE-2025-0684" title="CVE-2025-0684" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-0685" id="CVE-2025-0685" title="CVE-2025-0685" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-0686" id="CVE-2025-0686" title="CVE-2025-0686" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-0689" id="CVE-2025-0689" title="CVE-2025-0689" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-0690" id="CVE-2025-0690" title="CVE-2025-0690" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1118" id="CVE-2025-1118" title="CVE-2025-1118" type="cve"></reference>
          </references>
          <description>A flaw was found in grub2 where the grub_extcmd_dispatcher() function calls grub_arg_list_alloc() to allocate memory for the grub&#39;s argument list. However, it fails to check in case the memory allocation fails. Once the allocation fails, a NULL point will be processed by the parse_option() function, leading grub to crash or, in some rare scenarios, corrupt the IVT data.(CVE-2024-45775)When reading the language .mo file in grub_mofile_open(), grub2 fails to verify an integer overflow when allocating its internal buffer. A crafted .mo file may lead the buffer size calculation to overflow, leading to out-of-bound reads and writes. This flaw allows an attacker to leak sensitive data or overwrite critical data, possibly circumventing secure boot protections.(CVE-2024-45776)A flaw was found in grub2. The calculation of the translation buffer when reading a language .mo file in grub_gettext_getstr_from_position() may overflow, leading to a Out-of-bound write. This issue can be leveraged by an attacker to overwrite grub2&#39;s sensitive heap data, eventually leading to the circumvention of secure boot protections.(CVE-2024-45777)A flaw was found in grub2. When reading a symbolic link&#39;s name from a UFS filesystem, grub2 fails to validate the string length taken as an input. The lack of validation may lead to a heap out-of-bounds write, causing data integrity issues and eventually allowing an attacker to circumvent secure boot protections.(CVE-2024-45781)A flaw was found in the HFS filesystem. When reading an HFS volume&#39;s name at grub_fs_mount(), the HFS filesystem driver performs a strcpy() using the user-provided volume name as input without properly validating the volume name&#39;s length. This issue may read to a heap-based out-of-bounds writer, impacting grub&#39;s sensitive data integrity and eventually leading to a secure boot protection bypass.(CVE-2024-45782)A flaw was found in grub2. When failing to mount an HFS+ grub, the hfsplus filesystem driver doesn&#39;t properly set an ERRNO value. This issue may lead to a NULL pointer access.(CVE-2024-45783)A flaw was found in grub2. When reading data from a squash4 filesystem, grub&#39;s squash4 fs module uses user-controlled parameters from the filesystem geometry to determine the internal buffer size, however, it improperly checks for integer overflows. A maliciously crafted filesystem may lead some of those buffer size calculations to overflow, causing it to perform a grub_malloc() operation with a smaller size than expected. As a result, the direct_read() will perform a heap based out-of-bounds write during data reading. This flaw may be leveraged to corrupt grub&#39;s internal critical data and may result in arbitrary code execution, by-passing secure boot protections.(CVE-2025-0678)A flaw was found in grub2. When performing a symlink lookup from a reiserfs filesystem, grub&#39;s reiserfs fs module uses user-controlled parameters from the filesystem geometry to determine the internal buffer size, however, it improperly checks for integer overflows. A maliciouly crafted filesystem may lead some of those buffer size calculations to overflow, causing it to perform a grub_malloc() operation with a smaller size than expected. As a result, the grub_reiserfs_read_symlink() will call grub_reiserfs_read_real() with a overflown length parameter, leading to a heap based out-of-bounds write during data reading. This flaw may be leveraged to corrupt grub&#39;s internal critical data and can result in arbitrary code execution, by-passing secure boot protections.(CVE-2025-0684)A flaw was found in grub2. When reading data from a jfs filesystem, grub&#39;s jfs filesystem module uses user-controlled parameters from the filesystem geometry to determine the internal buffer size, however, it improperly checks for integer overflows. A maliciouly crafted filesystem may lead some of those buffer size calculations to overflow, causing it to perform a grub_malloc() operation with a smaller size than expected. As a result, the grub_jfs_lookup_symlink() function will write past the internal buffer length during grub_jfs_read_file(). This issue can be leveraged to corrupt grub&#39;s internal critical data and may result in arbitrary code execution, by-passing secure boot protections.(CVE-2025-0685)A flaw was found in grub2. When performing a symlink lookup from a romfs filesystem, grub&#39;s romfs filesystem module uses user-controlled parameters from the filesystem geometry to determine the internal buffer size, however, it improperly checks for integer overflows. A maliciously crafted filesystem may lead some of those buffer size calculations to overflow, causing it to perform a grub_malloc() operation with a smaller size than expected. As a result, the grub_romfs_read_symlink() may cause out-of-bounds writes when the calling grub_disk_read() function. This issue may be leveraged to corrupt grub&#39;s internal critical data and can result in arbitrary code execution by-passing secure boot protections.(CVE-2025-0686)When reading data from disk, the grub&#39;s UDF filesystem module utilizes the user controlled data length metadata to allocate its internal buffers. In certain scenarios, while iterating through disk sectors, it assumes the read size from the disk is always smaller than the allocated buffer size which is not guaranteed. A crafted filesystem image may lead to a heap-based buffer overflow resulting in critical data to be corrupted, resulting in the risk of arbitrary code execution by-passing secure boot protections.(CVE-2025-0689)The read command is used to read the keyboard input from the user, while reads it keeps the input length in a 32-bit integer value which is further used to reallocate the line buffer to accept the next character. During this process, with a line big enough it&#39;s possible to make this variable to overflow leading to a out-of-bounds write in the heap based buffer. This flaw may be leveraged to corrupt grub&#39;s internal critical data and secure boot bypass is not discarded as consequence.(CVE-2025-0690)A flaw was found in grub2. Grub&#39;s dump command is not blocked when grub is in lockdown mode, which allows the user to read any memory information, and an attacker may leverage this in order to extract signatures, salts, and other sensitive information from the memory.(CVE-2025-1118)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="grub2-debuginfo" release="51.oe2203sp4" version="2.06">
                         <filename>grub2-debuginfo-2.06-51.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="grub2-debugsource" release="51.oe2203sp4" version="2.06">
                         <filename>grub2-debugsource-2.06-51.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="grub2-efi-aa64" release="51.oe2203sp4" version="2.06">
                         <filename>grub2-efi-aa64-2.06-51.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="grub2-efi-aa64-cdboot" release="51.oe2203sp4" version="2.06">
                         <filename>grub2-efi-aa64-cdboot-2.06-51.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="grub2-tools" release="51.oe2203sp4" version="2.06">
                         <filename>grub2-tools-2.06-51.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="grub2-tools-extra" release="51.oe2203sp4" version="2.06">
                         <filename>grub2-tools-extra-2.06-51.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="grub2-tools-minimal" release="51.oe2203sp4" version="2.06">
                         <filename>grub2-tools-minimal-2.06-51.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="grub2-common" release="51.oe2203sp4" version="2.06">
                         <filename>grub2-common-2.06-51.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="grub2-efi-aa64-modules" release="51.oe2203sp4" version="2.06">
                         <filename>grub2-efi-aa64-modules-2.06-51.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="grub2-efi-ia32-modules" release="51.oe2203sp4" version="2.06">
                         <filename>grub2-efi-ia32-modules-2.06-51.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="grub2-efi-x64-modules" release="51.oe2203sp4" version="2.06">
                         <filename>grub2-efi-x64-modules-2.06-51.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="grub2-help" release="51.oe2203sp4" version="2.06">
                         <filename>grub2-help-2.06-51.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="grub2-pc-modules" release="51.oe2203sp4" version="2.06">
                         <filename>grub2-pc-modules-2.06-51.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-debuginfo" release="51.oe2203sp4" version="2.06">
                         <filename>grub2-debuginfo-2.06-51.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-debugsource" release="51.oe2203sp4" version="2.06">
                         <filename>grub2-debugsource-2.06-51.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-efi-ia32" release="51.oe2203sp4" version="2.06">
                         <filename>grub2-efi-ia32-2.06-51.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-efi-ia32-cdboot" release="51.oe2203sp4" version="2.06">
                         <filename>grub2-efi-ia32-cdboot-2.06-51.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-efi-x64" release="51.oe2203sp4" version="2.06">
                         <filename>grub2-efi-x64-2.06-51.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-efi-x64-cdboot" release="51.oe2203sp4" version="2.06">
                         <filename>grub2-efi-x64-cdboot-2.06-51.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-pc" release="51.oe2203sp4" version="2.06">
                         <filename>grub2-pc-2.06-51.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-tools" release="51.oe2203sp4" version="2.06">
                         <filename>grub2-tools-2.06-51.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-tools-efi" release="51.oe2203sp4" version="2.06">
                         <filename>grub2-tools-efi-2.06-51.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-tools-extra" release="51.oe2203sp4" version="2.06">
                         <filename>grub2-tools-extra-2.06-51.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-tools-minimal" release="51.oe2203sp4" version="2.06">
                         <filename>grub2-tools-minimal-2.06-51.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1294</id>
          <title>An update for pcp is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-03-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45769" id="CVE-2024-45769" title="CVE-2024-45769" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45770" id="CVE-2024-45770" title="CVE-2024-45770" type="cve"></reference>
          </references>
          <description>A vulnerability was found in Performance Co-Pilot (PCP).  This flaw allows an attacker to send specially crafted data to the system, which could cause the program to misbehave or crash.(CVE-2024-45769)A vulnerability was found in Performance Co-Pilot (PCP). This flaw can only be exploited if an attacker has access to a compromised PCP system account. The issue is related to the pmpost tool, which is used to log messages in the system. Under certain conditions, it runs with high-level privileges.(CVE-2024-45770)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="pcp" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-conf" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-conf-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-debuginfo" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-debuginfo-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-debugsource" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-debugsource-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-devel" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-devel-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-export-pcp2elasticsearch" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-export-pcp2elasticsearch-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-export-pcp2graphite" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-export-pcp2graphite-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-export-pcp2influxdb" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-export-pcp2influxdb-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-export-pcp2json" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-export-pcp2json-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-export-pcp2spark" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-export-pcp2spark-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-export-pcp2xml" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-export-pcp2xml-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-export-pcp2zabbix" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-export-pcp2zabbix-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-export-zabbix-agent" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-export-zabbix-agent-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-gui" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-gui-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-import-collectl2pcp" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-import-collectl2pcp-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-import-ganglia2pcp" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-import-ganglia2pcp-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-import-iostat2pcp" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-import-iostat2pcp-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-import-mrtg2pcp" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-import-mrtg2pcp-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-import-sar2pcp" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-import-sar2pcp-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-activemq" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-activemq-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-apache" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-apache-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-bash" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-bash-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-bind2" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-bind2-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-bonding" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-bonding-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-bpf" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-bpf-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-bpftrace" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-bpftrace-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-cifs" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-cifs-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-cisco" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-cisco-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-dbping" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-dbping-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-denki" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-denki-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-dm" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-dm-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-docker" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-docker-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-ds389" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-ds389-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-ds389log" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-ds389log-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-elasticsearch" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-elasticsearch-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-gfs2" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-gfs2-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-gluster" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-gluster-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-gpfs" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-gpfs-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-gpsd" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-gpsd-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-hacluster" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-hacluster-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-haproxy" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-haproxy-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-infiniband" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-infiniband-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-json" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-json-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-libvirt" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-libvirt-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-lio" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-lio-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-lmsensors" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-lmsensors-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-logger" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-logger-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-lustre" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-lustre-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-lustrecomm" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-lustrecomm-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-mailq" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-mailq-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-memcache" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-memcache-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-mic" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-mic-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-mongodb" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-mongodb-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-mounts" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-mounts-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-mysql" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-mysql-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-named" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-named-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-netcheck" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-netcheck-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-netfilter" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-netfilter-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-news" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-news-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-nfsclient" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-nfsclient-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-nginx" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-nginx-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-nutcracker" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-nutcracker-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-nvidia-gpu" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-nvidia-gpu-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-openmetrics" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-openmetrics-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-openvswitch" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-openvswitch-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-oracle" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-oracle-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-pdns" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-pdns-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-perfevent" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-perfevent-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-podman" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-podman-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-postfix" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-postfix-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-postgresql" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-postgresql-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-rabbitmq" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-rabbitmq-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-redis" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-redis-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-roomtemp" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-roomtemp-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-rsyslog" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-rsyslog-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-samba" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-samba-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-sendmail" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-sendmail-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-shping" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-shping-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-slurm" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-slurm-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-smart" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-smart-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-snmp" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-snmp-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-sockets" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-sockets-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-summary" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-summary-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-systemd" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-systemd-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-trace" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-trace-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-unbound" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-unbound-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-weblog" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-weblog-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-zimbra" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-zimbra-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-zswap" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-zswap-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-selinux" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-selinux-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-system-tools" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-system-tools-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-zeroconf" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-zeroconf-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perl-PCP-LogImport" release="7.oe2203sp4" version="5.3.7">
                         <filename>perl-PCP-LogImport-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perl-PCP-LogSummary" release="7.oe2203sp4" version="5.3.7">
                         <filename>perl-PCP-LogSummary-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perl-PCP-MMV" release="7.oe2203sp4" version="5.3.7">
                         <filename>perl-PCP-MMV-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perl-PCP-PMDA" release="7.oe2203sp4" version="5.3.7">
                         <filename>perl-PCP-PMDA-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-pcp" release="7.oe2203sp4" version="5.3.7">
                         <filename>python3-pcp-5.3.7-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="pcp-help" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-help-5.3.7-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-conf" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-conf-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-debuginfo" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-debuginfo-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-debugsource" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-debugsource-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-devel" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-devel-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-export-pcp2elasticsearch" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-export-pcp2elasticsearch-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-export-pcp2graphite" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-export-pcp2graphite-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-export-pcp2influxdb" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-export-pcp2influxdb-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-export-pcp2json" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-export-pcp2json-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-export-pcp2spark" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-export-pcp2spark-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-export-pcp2xml" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-export-pcp2xml-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-export-pcp2zabbix" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-export-pcp2zabbix-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-export-zabbix-agent" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-export-zabbix-agent-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-gui" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-gui-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-import-collectl2pcp" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-import-collectl2pcp-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-import-ganglia2pcp" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-import-ganglia2pcp-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-import-iostat2pcp" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-import-iostat2pcp-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-import-mrtg2pcp" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-import-mrtg2pcp-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-import-sar2pcp" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-import-sar2pcp-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-activemq" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-activemq-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-apache" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-apache-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-bash" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-bash-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-bcc" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-bcc-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-bind2" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-bind2-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-bonding" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-bonding-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-bpf" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-bpf-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-bpftrace" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-bpftrace-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-cifs" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-cifs-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-cisco" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-cisco-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-dbping" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-dbping-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-denki" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-denki-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-dm" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-dm-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-docker" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-docker-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-ds389" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-ds389-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-ds389log" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-ds389log-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-elasticsearch" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-elasticsearch-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-gfs2" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-gfs2-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-gluster" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-gluster-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-gpfs" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-gpfs-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-gpsd" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-gpsd-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-hacluster" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-hacluster-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-haproxy" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-haproxy-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-infiniband" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-infiniband-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-json" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-json-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-libvirt" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-libvirt-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-lio" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-lio-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-lmsensors" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-lmsensors-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-logger" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-logger-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-lustre" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-lustre-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-lustrecomm" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-lustrecomm-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-mailq" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-mailq-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-memcache" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-memcache-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-mic" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-mic-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-mongodb" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-mongodb-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-mounts" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-mounts-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-mssql" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-mssql-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-mysql" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-mysql-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-named" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-named-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-netcheck" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-netcheck-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-netfilter" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-netfilter-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-news" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-news-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-nfsclient" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-nfsclient-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-nginx" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-nginx-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-nutcracker" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-nutcracker-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-nvidia-gpu" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-nvidia-gpu-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-openmetrics" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-openmetrics-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-openvswitch" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-openvswitch-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-oracle" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-oracle-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-pdns" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-pdns-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-perfevent" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-perfevent-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-podman" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-podman-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-postfix" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-postfix-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-postgresql" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-postgresql-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-rabbitmq" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-rabbitmq-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-redis" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-redis-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-roomtemp" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-roomtemp-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-rsyslog" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-rsyslog-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-samba" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-samba-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-sendmail" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-sendmail-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-shping" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-shping-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-slurm" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-slurm-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-smart" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-smart-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-snmp" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-snmp-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-sockets" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-sockets-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-summary" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-summary-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-systemd" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-systemd-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-trace" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-trace-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-unbound" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-unbound-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-weblog" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-weblog-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-zimbra" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-zimbra-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-zswap" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-pmda-zswap-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-selinux" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-selinux-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-system-tools" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-system-tools-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-zeroconf" release="7.oe2203sp4" version="5.3.7">
                         <filename>pcp-zeroconf-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perl-PCP-LogImport" release="7.oe2203sp4" version="5.3.7">
                         <filename>perl-PCP-LogImport-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perl-PCP-LogSummary" release="7.oe2203sp4" version="5.3.7">
                         <filename>perl-PCP-LogSummary-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perl-PCP-MMV" release="7.oe2203sp4" version="5.3.7">
                         <filename>perl-PCP-MMV-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perl-PCP-PMDA" release="7.oe2203sp4" version="5.3.7">
                         <filename>perl-PCP-PMDA-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-pcp" release="7.oe2203sp4" version="5.3.7">
                         <filename>python3-pcp-5.3.7-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1296</id>
          <title>An update for libxslt is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-03-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-55549" id="CVE-2024-55549" title="CVE-2024-55549" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-24855" id="CVE-2025-24855" title="CVE-2025-24855" type="cve"></reference>
          </references>
          <description>xsltGetInheritedNsList in libxslt before 1.1.43 has a use-after-free issue related to exclusion of result prefixes.(CVE-2024-55549)numbers.c in libxslt before 1.1.43 has a use-after-free because, in nested XPath evaluations, an XPath context node can be modified but never restored. This is related to xsltNumberFormatGetValue, xsltEvalXPathPredicate, xsltEvalXPathStringNs, and xsltComputeSortResultInternal.(CVE-2025-24855)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libxslt" release="2.oe2203sp4" version="1.1.37">
                         <filename>libxslt-1.1.37-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libxslt-debuginfo" release="2.oe2203sp4" version="1.1.37">
                         <filename>libxslt-debuginfo-1.1.37-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libxslt-debugsource" release="2.oe2203sp4" version="1.1.37">
                         <filename>libxslt-debugsource-1.1.37-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libxslt-devel" release="2.oe2203sp4" version="1.1.37">
                         <filename>libxslt-devel-1.1.37-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-libxslt" release="2.oe2203sp4" version="1.1.37">
                         <filename>python3-libxslt-1.1.37-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="libxslt-help" release="2.oe2203sp4" version="1.1.37">
                         <filename>libxslt-help-1.1.37-2.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libxslt" release="2.oe2203sp4" version="1.1.37">
                         <filename>libxslt-1.1.37-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libxslt-debuginfo" release="2.oe2203sp4" version="1.1.37">
                         <filename>libxslt-debuginfo-1.1.37-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libxslt-debugsource" release="2.oe2203sp4" version="1.1.37">
                         <filename>libxslt-debugsource-1.1.37-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libxslt-devel" release="2.oe2203sp4" version="1.1.37">
                         <filename>libxslt-devel-1.1.37-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-libxslt" release="2.oe2203sp4" version="1.1.37">
                         <filename>python3-libxslt-1.1.37-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1299</id>
          <title>An update for rubygem-rack is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-03-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-25184" id="CVE-2025-25184" title="CVE-2025-25184" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-27111" id="CVE-2025-27111" title="CVE-2025-27111" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-27610" id="CVE-2025-27610" title="CVE-2025-27610" type="cve"></reference>
          </references>
          <description>Rack provides an interface for developing web applications in Ruby. Prior to versions 2.2.11, 3.0.12, and 3.1.10, Rack::CommonLogger can be exploited by crafting input that includes newline characters to manipulate log entries. The supplied proof-of-concept demonstrates injecting malicious content into logs. When a user provides the authorization credentials via Rack::Auth::Basic, if success, the username will be put in env[&#39;REMOTE_USER&#39;] and later be used by Rack::CommonLogger for logging purposes. The issue occurs when a server intentionally or unintentionally allows a user creation with the username contain CRLF and white space characters, or the server just want to log every login attempts. If an attacker enters a username with CRLF character, the logger will log the malicious username with CRLF characters into the logfile. Attackers can break log formats or insert fraudulent entries, potentially obscuring real activity or injecting malicious data into log files. Versions 2.2.11, 3.0.12, and 3.1.10 contain a fix.(CVE-2025-25184)Rack is a modular Ruby web server interface. The Rack::Sendfile middleware logs unsanitised header values from the X-Sendfile-Type header. An attacker can exploit this by injecting escape sequences (such as newline characters) into the header, resulting in log injection. This vulnerability is fixed in 2.2.12, 3.0.13, and 3.1.11.(CVE-2025-27111)Rack provides an interface for developing web applications in Ruby. Prior to versions 2.2.13, 3.0.14, and 3.1.12, `Rack::Static` can serve files under the specified `root:` even if `urls:` are provided, which may expose other files under the specified `root:` unexpectedly. The vulnerability occurs because `Rack::Static` does not properly sanitize user-supplied paths before serving files. Specifically, encoded path traversal sequences are not correctly validated, allowing attackers to access files outside the designated static file directory. By exploiting this vulnerability, an attacker can gain access to all files under the specified `root:` directory, provided they are able to determine then path of the file. Versions 2.2.13, 3.0.14, and 3.1.12 contain a patch for the issue. Other mitigations include removing usage of `Rack::Static`, or ensuring that `root:` points at a directory path which only contains files which should be accessed publicly. It is likely that a CDN or similar static file server would also mitigate the issue.(CVE-2025-27610)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="noarch" name="rubygem-rack" release="8.oe2203sp4" version="2.2.3.1">
                         <filename>rubygem-rack-2.2.3.1-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="rubygem-rack-help" release="8.oe2203sp4" version="2.2.3.1">
                         <filename>rubygem-rack-help-2.2.3.1-8.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1300</id>
          <title>An update for freetype is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-03-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-27363" id="CVE-2025-27363" title="CVE-2025-27363" type="cve"></reference>
          </references>
          <description>An out of bounds write exists in FreeType versions 2.13.0 and below (newer versions of FreeType are not vulnerable) when attempting to parse font subglyph structures related to TrueType GX and variable font files. The vulnerable code assigns a signed short value to an unsigned long and then adds a static value causing it to wrap around and allocate too small of a heap buffer. The code then writes up to 6 signed long integers out of bounds relative to this buffer. This may result in arbitrary code execution. This vulnerability may have been exploited in the wild.(CVE-2025-27363)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="freetype" release="4.oe2203sp4" version="2.12.1">
                         <filename>freetype-2.12.1-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="freetype-debuginfo" release="4.oe2203sp4" version="2.12.1">
                         <filename>freetype-debuginfo-2.12.1-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="freetype-debugsource" release="4.oe2203sp4" version="2.12.1">
                         <filename>freetype-debugsource-2.12.1-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="freetype-demos" release="4.oe2203sp4" version="2.12.1">
                         <filename>freetype-demos-2.12.1-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="freetype-devel" release="4.oe2203sp4" version="2.12.1">
                         <filename>freetype-devel-2.12.1-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="freetype-help" release="4.oe2203sp4" version="2.12.1">
                         <filename>freetype-help-2.12.1-4.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freetype" release="4.oe2203sp4" version="2.12.1">
                         <filename>freetype-2.12.1-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freetype-debuginfo" release="4.oe2203sp4" version="2.12.1">
                         <filename>freetype-debuginfo-2.12.1-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freetype-debugsource" release="4.oe2203sp4" version="2.12.1">
                         <filename>freetype-debugsource-2.12.1-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freetype-demos" release="4.oe2203sp4" version="2.12.1">
                         <filename>freetype-demos-2.12.1-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freetype-devel" release="4.oe2203sp4" version="2.12.1">
                         <filename>freetype-devel-2.12.1-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1305</id>
          <title>An update for php is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-03-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1217" id="CVE-2025-1217" title="CVE-2025-1217" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1219" id="CVE-2025-1219" title="CVE-2025-1219" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1734" id="CVE-2025-1734" title="CVE-2025-1734" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1736" id="CVE-2025-1736" title="CVE-2025-1736" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-1861" id="CVE-2025-1861" title="CVE-2025-1861" type="cve"></reference>
          </references>
          <description>(CVE-2025-1217)(CVE-2025-1219)(CVE-2025-1734)(CVE-2025-1736)(CVE-2025-1861)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="php" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-8.0.30-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-bcmath" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-bcmath-8.0.30-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-cli" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-cli-8.0.30-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-common" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-common-8.0.30-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-dba" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-dba-8.0.30-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-dbg" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-dbg-8.0.30-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-debuginfo" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-debuginfo-8.0.30-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-debugsource" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-debugsource-8.0.30-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-devel" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-devel-8.0.30-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-embedded" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-embedded-8.0.30-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-enchant" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-enchant-8.0.30-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-ffi" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-ffi-8.0.30-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-fpm" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-fpm-8.0.30-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-gd" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-gd-8.0.30-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-gmp" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-gmp-8.0.30-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-intl" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-intl-8.0.30-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-ldap" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-ldap-8.0.30-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-mbstring" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-mbstring-8.0.30-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-mysqlnd" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-mysqlnd-8.0.30-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-odbc" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-odbc-8.0.30-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-opcache" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-opcache-8.0.30-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-pdo" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-pdo-8.0.30-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-pgsql" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-pgsql-8.0.30-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-process" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-process-8.0.30-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-snmp" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-snmp-8.0.30-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-soap" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-soap-8.0.30-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-sodium" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-sodium-8.0.30-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-tidy" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-tidy-8.0.30-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-xml" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-xml-8.0.30-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="php-help" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-help-8.0.30-9.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-8.0.30-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-bcmath" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-bcmath-8.0.30-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-cli" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-cli-8.0.30-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-common" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-common-8.0.30-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-dba" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-dba-8.0.30-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-dbg" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-dbg-8.0.30-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-debuginfo" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-debuginfo-8.0.30-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-debugsource" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-debugsource-8.0.30-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-devel" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-devel-8.0.30-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-embedded" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-embedded-8.0.30-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-enchant" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-enchant-8.0.30-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-ffi" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-ffi-8.0.30-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-fpm" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-fpm-8.0.30-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-gd" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-gd-8.0.30-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-gmp" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-gmp-8.0.30-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-intl" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-intl-8.0.30-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-ldap" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-ldap-8.0.30-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-mbstring" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-mbstring-8.0.30-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-mysqlnd" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-mysqlnd-8.0.30-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-odbc" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-odbc-8.0.30-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-opcache" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-opcache-8.0.30-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-pdo" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-pdo-8.0.30-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-pgsql" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-pgsql-8.0.30-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-process" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-process-8.0.30-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-snmp" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-snmp-8.0.30-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-soap" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-soap-8.0.30-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-sodium" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-sodium-8.0.30-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-tidy" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-tidy-8.0.30-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-xml" release="9.oe2203sp4" version="8.0.30">
                         <filename>php-xml-8.0.30-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1307</id>
          <title>An update for linux-firmware is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-03-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56161" id="CVE-2024-56161" title="CVE-2024-56161" type="cve"></reference>
          </references>
          <description>Improper signature verification in AMD CPU ROM microcode patch loader may allow an attacker with local administrator privilege to load malicious CPU microcode resulting in loss of confidentiality and integrity of a confidential guest running under AMD SEV-SNP.(CVE-2024-56161)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="linux-firmware" release="1.oe2203sp4" version="20250311">
                         <filename>linux-firmware-20250311-1.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="linux-firmware-ath" release="1.oe2203sp4" version="20250311">
                         <filename>linux-firmware-ath-20250311-1.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="linux-firmware-cypress" release="1.oe2203sp4" version="20250311">
                         <filename>linux-firmware-cypress-20250311-1.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="linux-firmware-iwlwifi" release="1.oe2203sp4" version="20250311">
                         <filename>linux-firmware-iwlwifi-20250311-1.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="linux-firmware-libertas" release="1.oe2203sp4" version="20250311">
                         <filename>linux-firmware-libertas-20250311-1.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="linux-firmware-mediatek" release="1.oe2203sp4" version="20250311">
                         <filename>linux-firmware-mediatek-20250311-1.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="linux-firmware-mrvl" release="1.oe2203sp4" version="20250311">
                         <filename>linux-firmware-mrvl-20250311-1.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="linux-firmware-netronome" release="1.oe2203sp4" version="20250311">
                         <filename>linux-firmware-netronome-20250311-1.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="linux-firmware-ti-connectivity" release="1.oe2203sp4" version="20250311">
                         <filename>linux-firmware-ti-connectivity-20250311-1.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1308</id>
          <title>An update for zvbi is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-03-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-2174" id="CVE-2025-2174" title="CVE-2025-2174" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-2176" id="CVE-2025-2176" title="CVE-2025-2176" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-2177" id="CVE-2025-2177" title="CVE-2025-2177" type="cve"></reference>
          </references>
          <description>A vulnerability was found in libzvbi up to 0.2.43. It has been declared as problematic. Affected by this vulnerability is the function vbi_strndup_iconv_ucs2 of the file src/conv.c. The manipulation of the argument src_length leads to integer overflow. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. Upgrading to version 0.2.44 is able to address this issue. The patch is named ca1672134b3e2962cd392212c73f44f8f4cb489f. It is recommended to upgrade the affected component. The code maintainer was informed beforehand about the issues. She reacted very fast and highly professional.(CVE-2025-2174)A vulnerability classified as critical has been found in libzvbi up to 0.2.43. This affects the function vbi_capture_sim_load_caption of the file src/io-sim.c. The manipulation leads to integer overflow. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used. Upgrading to version 0.2.44 is able to address this issue. The identifier of the patch is ca1672134b3e2962cd392212c73f44f8f4cb489f. It is recommended to upgrade the affected component. The code maintainer was informed beforehand about the issues. She reacted very fast and highly professional.(CVE-2025-2176)A vulnerability classified as critical was found in libzvbi up to 0.2.43. This vulnerability affects the function vbi_search_new of the file src/search.c. The manipulation of the argument pat_len leads to integer overflow. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. Upgrading to version 0.2.44 is able to address this issue. The patch is identified as ca1672134b3e2962cd392212c73f44f8f4cb489f. It is recommended to upgrade the affected component. The code maintainer was informed beforehand about the issues. She reacted very fast and highly professional.(CVE-2025-2177)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="zvbi" release="9.oe2203sp4" version="0.2.35">
                         <filename>zvbi-0.2.35-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="zvbi-debuginfo" release="9.oe2203sp4" version="0.2.35">
                         <filename>zvbi-debuginfo-0.2.35-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="zvbi-debugsource" release="9.oe2203sp4" version="0.2.35">
                         <filename>zvbi-debugsource-0.2.35-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="zvbi-devel" release="9.oe2203sp4" version="0.2.35">
                         <filename>zvbi-devel-0.2.35-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="zvbi-help" release="9.oe2203sp4" version="0.2.35">
                         <filename>zvbi-help-0.2.35-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="zvbi" release="9.oe2203sp4" version="0.2.35">
                         <filename>zvbi-0.2.35-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="zvbi-debuginfo" release="9.oe2203sp4" version="0.2.35">
                         <filename>zvbi-debuginfo-0.2.35-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="zvbi-debugsource" release="9.oe2203sp4" version="0.2.35">
                         <filename>zvbi-debugsource-0.2.35-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="zvbi-devel" release="9.oe2203sp4" version="0.2.35">
                         <filename>zvbi-devel-0.2.35-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="zvbi-help" release="9.oe2203sp4" version="0.2.35">
                         <filename>zvbi-help-0.2.35-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1309</id>
          <title>An update for libarchive is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-03-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-25724" id="CVE-2025-25724" title="CVE-2025-25724" type="cve"></reference>
          </references>
          <description>list_item_verbose in tar/util.c in libarchive through 3.7.7 does not check an strftime return value, which can lead to a denial of service or unspecified other impact via a crafted TAR archive that is read with a verbose value of 2. For example, the 100-byte buffer may not be sufficient for a custom locale.(CVE-2025-25724)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="bsdcat" release="8.oe2203sp4" version="3.5.2">
                         <filename>bsdcat-3.5.2-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bsdcpio" release="8.oe2203sp4" version="3.5.2">
                         <filename>bsdcpio-3.5.2-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bsdtar" release="8.oe2203sp4" version="3.5.2">
                         <filename>bsdtar-3.5.2-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libarchive" release="8.oe2203sp4" version="3.5.2">
                         <filename>libarchive-3.5.2-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libarchive-debuginfo" release="8.oe2203sp4" version="3.5.2">
                         <filename>libarchive-debuginfo-3.5.2-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libarchive-debugsource" release="8.oe2203sp4" version="3.5.2">
                         <filename>libarchive-debugsource-3.5.2-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libarchive-devel" release="8.oe2203sp4" version="3.5.2">
                         <filename>libarchive-devel-3.5.2-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="libarchive-help" release="8.oe2203sp4" version="3.5.2">
                         <filename>libarchive-help-3.5.2-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bsdcat" release="8.oe2203sp4" version="3.5.2">
                         <filename>bsdcat-3.5.2-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bsdcpio" release="8.oe2203sp4" version="3.5.2">
                         <filename>bsdcpio-3.5.2-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bsdtar" release="8.oe2203sp4" version="3.5.2">
                         <filename>bsdtar-3.5.2-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libarchive" release="8.oe2203sp4" version="3.5.2">
                         <filename>libarchive-3.5.2-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libarchive-debuginfo" release="8.oe2203sp4" version="3.5.2">
                         <filename>libarchive-debuginfo-3.5.2-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libarchive-debugsource" release="8.oe2203sp4" version="3.5.2">
                         <filename>libarchive-debugsource-3.5.2-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libarchive-devel" release="8.oe2203sp4" version="3.5.2">
                         <filename>libarchive-devel-3.5.2-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1316</id>
          <title>An update for openssh is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-03-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-26465" id="CVE-2025-26465" title="CVE-2025-26465" type="cve"></reference>
          </references>
          <description>A vulnerability was found in OpenSSH when the VerifyHostKeyDNS option is enabled. A machine-in-the-middle attack can be performed by a malicious machine impersonating a legit server. This issue occurs due to how OpenSSH mishandles error codes in specific conditions when verifying the host key. For an attack to be considered successful, the attacker needs to manage to exhaust the client&#39;s memory resource first, turning the attack complexity high.(CVE-2025-26465)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="openssh" release="34.oe2203sp4" version="8.8p1">
                         <filename>openssh-8.8p1-34.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-askpass" release="34.oe2203sp4" version="8.8p1">
                         <filename>openssh-askpass-8.8p1-34.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-clients" release="34.oe2203sp4" version="8.8p1">
                         <filename>openssh-clients-8.8p1-34.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-debuginfo" release="34.oe2203sp4" version="8.8p1">
                         <filename>openssh-debuginfo-8.8p1-34.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-debugsource" release="34.oe2203sp4" version="8.8p1">
                         <filename>openssh-debugsource-8.8p1-34.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-keycat" release="34.oe2203sp4" version="8.8p1">
                         <filename>openssh-keycat-8.8p1-34.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-server" release="34.oe2203sp4" version="8.8p1">
                         <filename>openssh-server-8.8p1-34.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pam_ssh_agent_auth" release="4.34.oe2203sp4" version="0.10.4">
                         <filename>pam_ssh_agent_auth-0.10.4-4.34.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="openssh-help" release="34.oe2203sp4" version="8.8p1">
                         <filename>openssh-help-8.8p1-34.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh" release="34.oe2203sp4" version="8.8p1">
                         <filename>openssh-8.8p1-34.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-askpass" release="34.oe2203sp4" version="8.8p1">
                         <filename>openssh-askpass-8.8p1-34.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-clients" release="34.oe2203sp4" version="8.8p1">
                         <filename>openssh-clients-8.8p1-34.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-debuginfo" release="34.oe2203sp4" version="8.8p1">
                         <filename>openssh-debuginfo-8.8p1-34.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-debugsource" release="34.oe2203sp4" version="8.8p1">
                         <filename>openssh-debugsource-8.8p1-34.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-keycat" release="34.oe2203sp4" version="8.8p1">
                         <filename>openssh-keycat-8.8p1-34.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-server" release="34.oe2203sp4" version="8.8p1">
                         <filename>openssh-server-8.8p1-34.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pam_ssh_agent_auth" release="4.34.oe2203sp4" version="0.10.4">
                         <filename>pam_ssh_agent_auth-0.10.4-4.34.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1319</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-03-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-58058" id="CVE-2024-58058" title="CVE-2024-58058" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21662" id="CVE-2025-21662" title="CVE-2025-21662" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:ubifs: skip dumping tnc tree when zroot is nullClearing slab cache will free all znode in memory and makec-&gt;zroot.znode = NULL, then dumping tnc tree will accessc-&gt;zroot.znode which cause null pointer dereference.(CVE-2024-58058)In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Fix variable not being completed when function returnsWhen cmd_alloc_index(), fails cmd_work_handler() needsto complete ent-&gt;slotted before returning early.Otherwise the task which issued the command may hang:   mlx5_core 0000:01:00.0: cmd_work_handler:877:(pid 3880418): failed to allocate command entry   INFO: task kworker/13:2:4055883 blocked for more than 120 seconds.         Not tainted 4.19.90-25.44.v2101.ky10.aarch64 #1   &#34;echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs&#34; disables this message.   kworker/13:2    D    0 4055883      2 0x00000228   Workqueue: events mlx5e_tx_dim_work [mlx5_core]   Call trace:      __switch_to+0xe8/0x150      __schedule+0x2a8/0x9b8      schedule+0x2c/0x88      schedule_timeout+0x204/0x478      wait_for_common+0x154/0x250      wait_for_completion+0x28/0x38      cmd_exec+0x7a0/0xa00 [mlx5_core]      mlx5_cmd_exec+0x54/0x80 [mlx5_core]      mlx5_core_modify_cq+0x6c/0x80 [mlx5_core]      mlx5_core_modify_cq_moderation+0xa0/0xb8 [mlx5_core]      mlx5e_tx_dim_work+0x54/0x68 [mlx5_core]      process_one_work+0x1b0/0x448      worker_thread+0x54/0x468      kthread+0x134/0x138      ret_from_fork+0x10/0x18(CVE-2025-21662)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="bpftool" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-254.0.0.158.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-254.0.0.158.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-254.0.0.158.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-254.0.0.158.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-254.0.0.158.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-254.0.0.158.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-254.0.0.158.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-254.0.0.158.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-254.0.0.158.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-254.0.0.158.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-254.0.0.158.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-254.0.0.158.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-254.0.0.158.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-254.0.0.158.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-254.0.0.158.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-254.0.0.158.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-254.0.0.158.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-254.0.0.158.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-254.0.0.158.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-254.0.0.158.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-254.0.0.158.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-254.0.0.158.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-254.0.0.158.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-254.0.0.158.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-254.0.0.158.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-254.0.0.158.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-254.0.0.158.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-254.0.0.158.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-254.0.0.158.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="254.0.0.158.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-254.0.0.158.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1323</id>
          <title>An update for firefox is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2025-03-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6135" id="CVE-2023-6135" title="CVE-2023-6135" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6207" id="CVE-2023-6207" title="CVE-2023-6207" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6208" id="CVE-2023-6208" title="CVE-2023-6208" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6209" id="CVE-2023-6209" title="CVE-2023-6209" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6210" id="CVE-2023-6210" title="CVE-2023-6210" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6211" id="CVE-2023-6211" title="CVE-2023-6211" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6212" id="CVE-2023-6212" title="CVE-2023-6212" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6213" id="CVE-2023-6213" title="CVE-2023-6213" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6856" id="CVE-2023-6856" title="CVE-2023-6856" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6857" id="CVE-2023-6857" title="CVE-2023-6857" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6858" id="CVE-2023-6858" title="CVE-2023-6858" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6861" id="CVE-2023-6861" title="CVE-2023-6861" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6862" id="CVE-2023-6862" title="CVE-2023-6862" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6864" id="CVE-2023-6864" title="CVE-2023-6864" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6865" id="CVE-2023-6865" title="CVE-2023-6865" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6867" id="CVE-2023-6867" title="CVE-2023-6867" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6871" id="CVE-2023-6871" title="CVE-2023-6871" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6872" id="CVE-2023-6872" title="CVE-2023-6872" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6873" id="CVE-2023-6873" title="CVE-2023-6873" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0741" id="CVE-2024-0741" title="CVE-2024-0741" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0742" id="CVE-2024-0742" title="CVE-2024-0742" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0744" id="CVE-2024-0744" title="CVE-2024-0744" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0747" id="CVE-2024-0747" title="CVE-2024-0747" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0749" id="CVE-2024-0749" title="CVE-2024-0749" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0751" id="CVE-2024-0751" title="CVE-2024-0751" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0753" id="CVE-2024-0753" title="CVE-2024-0753" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0755" id="CVE-2024-0755" title="CVE-2024-0755" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5692" id="CVE-2024-5692" title="CVE-2024-5692" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5694" id="CVE-2024-5694" title="CVE-2024-5694" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5695" id="CVE-2024-5695" title="CVE-2024-5695" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5698" id="CVE-2024-5698" title="CVE-2024-5698" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5699" id="CVE-2024-5699" title="CVE-2024-5699" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5700" id="CVE-2024-5700" title="CVE-2024-5700" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5701" id="CVE-2024-5701" title="CVE-2024-5701" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5702" id="CVE-2024-5702" title="CVE-2024-5702" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-8386" id="CVE-2024-8386" title="CVE-2024-8386" type="cve"></reference>
          </references>
          <description>Multiple NSS NIST curves were susceptible to a side-channel attack known as &#34;Minerva&#34;. This attack could potentially allow an attacker to recover the private key. This vulnerability affects Firefox &lt; 121.(CVE-2023-6135)Ownership mismanagement led to a use-after-free in ReadableByteStreams This vulnerability affects Firefox &lt; 120, Firefox ESR &lt; 115.5.0, and Thunderbird &lt; 115.5.(CVE-2023-6207)When using X11, text selected by the page using the Selection API was erroneously copied into the primary selection, a temporary storage not unlike the clipboard.*This bug only affects Firefox on X11. Other systems are unaffected.* This vulnerability affects Firefox &lt; 120, Firefox ESR &lt; 115.5.0, and Thunderbird &lt; 115.5.(CVE-2023-6208)Relative URLs starting with three slashes were incorrectly parsed, and a path-traversal &#34;/../&#34; part in the path could be used to override the specified host. This could contribute to security problems in web sites. This vulnerability affects Firefox &lt; 120, Firefox ESR &lt; 115.5.0, and Thunderbird &lt; 115.5.(CVE-2023-6209)When an https: web page created a pop-up from a &#34;javascript:&#34; URL, that pop-up was incorrectly allowed to load blockable content such as iframes from insecure http: URLs This vulnerability affects Firefox &lt; 120.(CVE-2023-6210)If an attacker needed a user to load an insecure http: page and knew that user had enabled HTTPS-only mode, the attacker could have tricked the user into clicking to grant an HTTPS-only exception if they could get the user to participate in a clicking game. This vulnerability affects Firefox &lt; 120.(CVE-2023-6211)Memory safety bugs present in Firefox 119, Firefox ESR 115.4, and Thunderbird 115.4. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 120, Firefox ESR &lt; 115.5.0, and Thunderbird &lt; 115.5.(CVE-2023-6212)Memory safety bugs present in Firefox 119. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 120.(CVE-2023-6213)The WebGL `DrawElementsInstanced` method was susceptible to a heap buffer overflow when used on systems with the Mesa VM driver.  This issue could allow an attacker to perform remote code execution and sandbox escape. This vulnerability affects Firefox ESR &lt; 115.6, Thunderbird &lt; 115.6, and Firefox &lt; 121.(CVE-2023-6856)When resolving a symlink, a race may occur where the buffer passed to `readlink` may actually be smaller than necessary. *This bug only affects Firefox on Unix-based operating systems (Android, Linux, MacOS). Windows is unaffected.* This vulnerability affects Firefox ESR &lt; 115.6, Thunderbird &lt; 115.6, and Firefox &lt; 121.(CVE-2023-6857)Firefox was susceptible to a heap buffer overflow in `nsTextFragment` due to insufficient OOM handling. This vulnerability affects Firefox ESR &lt; 115.6, Thunderbird &lt; 115.6, and Firefox &lt; 121.(CVE-2023-6858)The `nsWindow::PickerOpen(void)` method was susceptible to a heap buffer overflow when running in headless mode. This vulnerability affects Firefox ESR &lt; 115.6, Thunderbird &lt; 115.6, and Firefox &lt; 121.(CVE-2023-6861)A use-after-free was identified in the `nsDNSService::Init`.  This issue appears to manifest rarely during start-up. This vulnerability affects Firefox ESR &lt; 115.6 and Thunderbird &lt; 115.6.(CVE-2023-6862)Memory safety bugs present in Firefox 120, Firefox ESR 115.5, and Thunderbird 115.5. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox ESR &lt; 115.6, Thunderbird &lt; 115.6, and Firefox &lt; 121.(CVE-2023-6864)`EncryptingOutputStream` was susceptible to exposing uninitialized data.  This issue could only be abused in order to write data to a local disk which may have implications for private browsing mode. This vulnerability affects Firefox ESR &lt; 115.6 and Firefox &lt; 121.(CVE-2023-6865)The timing of a button click causing a popup to disappear was approximately the same length as the anti-clickjacking delay on permission prompts. It was possible to use this fact to surprise users by luring them to click where the permission grant button would be about to appear. This vulnerability affects Firefox ESR &lt; 115.6 and Firefox &lt; 121.(CVE-2023-6867)Under certain conditions, Firefox did not display a warning when a user attempted to navigate to a new protocol handler. This vulnerability affects Firefox &lt; 121.(CVE-2023-6871)Browser tab titles were being leaked by GNOME to system logs. This could potentially expose the browsing habits of users running in a private tab. This vulnerability affects Firefox &lt; 121.(CVE-2023-6872)Memory safety bugs present in Firefox 120. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 121.(CVE-2023-6873)An out of bounds write in ANGLE could have allowed an attacker to corrupt memory leading to a potentially exploitable crash. This vulnerability affects Firefox &lt; 122, Firefox ESR &lt; 115.7, and Thunderbird &lt; 115.7.(CVE-2024-0741)It was possible for certain browser prompts and dialogs to be activated or dismissed unintentionally by the user due to an incorrect timestamp used to prevent input after page load. This vulnerability affects Firefox &lt; 122, Firefox ESR &lt; 115.7, and Thunderbird &lt; 115.7.(CVE-2024-0742)In some circumstances, JIT compiled code could have dereferenced a wild pointer value. This could have led to an exploitable crash. This vulnerability affects Firefox &lt; 122.(CVE-2024-0744)When a parent page loaded a child in an iframe with `unsafe-inline`, the parent Content Security Policy could have overridden the child Content Security Policy. This vulnerability affects Firefox &lt; 122, Firefox ESR &lt; 115.7, and Thunderbird &lt; 115.7.(CVE-2024-0747)A phishing site could have repurposed an `about:` dialog to show phishing content with an incorrect origin in the address bar. This vulnerability affects Firefox &lt; 122 and Thunderbird &lt; 115.7.(CVE-2024-0749)A malicious devtools extension could have been used to escalate privileges. This vulnerability affects Firefox &lt; 122, Firefox ESR &lt; 115.7, and Thunderbird &lt; 115.7.(CVE-2024-0751)In specific HSTS configurations an attacker could have bypassed HSTS on a subdomain. This vulnerability affects Firefox &lt; 122, Firefox ESR &lt; 115.7, and Thunderbird &lt; 115.7.(CVE-2024-0753)Memory safety bugs present in Firefox 121, Firefox ESR 115.6, and Thunderbird 115.6. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 122, Firefox ESR &lt; 115.7, and Thunderbird &lt; 115.7.(CVE-2024-0755)On Windows 10, when using the &#39;Save As&#39; functionality, an attacker could have tricked the browser into saving the file with a disallowed extension such as `.url` by including an invalid character in the extension. *Note:* This issue only affected Windows operating systems. Other operating systems are unaffected. This vulnerability affects Firefox &lt; 127, Firefox ESR &lt; 115.12, and Thunderbird &lt; 115.12.(CVE-2024-5692)An attacker could have caused a use-after-free in the JavaScript engine to read memory in the JavaScript string section of the heap. This vulnerability affects Firefox &lt; 127.(CVE-2024-5694)If an out-of-memory condition occurs at a specific point using allocations in the probabilistic heap checker, an assertion could have been triggered, and in rarer situations, memory corruption could have occurred. This vulnerability affects Firefox &lt; 127.(CVE-2024-5695)By manipulating the fullscreen feature while opening a data-list, an attacker could have overlaid a text box over the address bar. This could have led to user confusion and possible spoofing attacks. This vulnerability affects Firefox &lt; 127.(CVE-2024-5698)In violation of spec, cookie prefixes such as `__Secure` were being ignored if they were not correctly capitalized - by spec they should be checked with a case-insensitive comparison. This could have resulted in the browser not correctly honoring the behaviors specified by the prefix. This vulnerability affects Firefox &lt; 127.(CVE-2024-5699)Memory safety bugs present in Firefox 126, Firefox ESR 115.11, and Thunderbird 115.11. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 127, Firefox ESR &lt; 115.12, and Thunderbird &lt; 115.12.(CVE-2024-5700)Memory safety bugs present in Firefox 126. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 127.(CVE-2024-5701)Memory corruption in the networking stack could have led to a potentially exploitable crash. This vulnerability affects Firefox &lt; 125, Firefox ESR &lt; 115.12, and Thunderbird &lt; 115.12.(CVE-2024-5702)If a site had been granted the permission to open popup windows, it could cause Select elements to appear on top of another site to perform a spoofing attack. This vulnerability affects Firefox &lt; 130, Firefox ESR &lt; 128.2, and Thunderbird &lt; 128.2.(CVE-2024-8386)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="firefox" release="1.oe2203sp4" version="128.8.0">
                         <filename>firefox-128.8.0-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="firefox-debuginfo" release="1.oe2203sp4" version="128.8.0">
                         <filename>firefox-debuginfo-128.8.0-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="firefox-debugsource" release="1.oe2203sp4" version="128.8.0">
                         <filename>firefox-debugsource-128.8.0-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox" release="1.oe2203sp4" version="128.8.0">
                         <filename>firefox-128.8.0-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox-debuginfo" release="1.oe2203sp4" version="128.8.0">
                         <filename>firefox-debuginfo-128.8.0-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox-debugsource" release="1.oe2203sp4" version="128.8.0">
                         <filename>firefox-debugsource-128.8.0-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1328</id>
          <title>An update for assimp is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-03-29"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-2151" id="CVE-2025-2151" title="CVE-2025-2151" type="cve"></reference>
          </references>
          <description>A vulnerability classified as critical was found in Open Asset Import Library Assimp 5.4.3. This vulnerability affects the function Assimp::GetNextLine in the library ParsingUtils.h of the component File Handler. The manipulation leads to stack-based buffer overflow. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used.(CVE-2025-2151)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="assimp" release="5.oe2203sp4" version="5.2.4">
                         <filename>assimp-5.2.4-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="assimp-debuginfo" release="5.oe2203sp4" version="5.2.4">
                         <filename>assimp-debuginfo-5.2.4-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="assimp-debugsource" release="5.oe2203sp4" version="5.2.4">
                         <filename>assimp-debugsource-5.2.4-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="assimp-devel" release="5.oe2203sp4" version="5.2.4">
                         <filename>assimp-devel-5.2.4-5.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="assimp-help" release="5.oe2203sp4" version="5.2.4">
                         <filename>assimp-help-5.2.4-5.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-assimp" release="5.oe2203sp4" version="5.2.4">
                         <filename>python3-assimp-5.2.4-5.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="assimp" release="5.oe2203sp4" version="5.2.4">
                         <filename>assimp-5.2.4-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="assimp-debuginfo" release="5.oe2203sp4" version="5.2.4">
                         <filename>assimp-debuginfo-5.2.4-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="assimp-debugsource" release="5.oe2203sp4" version="5.2.4">
                         <filename>assimp-debugsource-5.2.4-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="assimp-devel" release="5.oe2203sp4" version="5.2.4">
                         <filename>assimp-devel-5.2.4-5.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1330</id>
          <title>An update for zvbi is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-03-29"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-2173" id="CVE-2025-2173" title="CVE-2025-2173" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-2175" id="CVE-2025-2175" title="CVE-2025-2175" type="cve"></reference>
          </references>
          <description>A vulnerability was found in libzvbi up to 0.2.43. It has been classified as problematic. Affected is the function vbi_strndup_iconv_ucs2 of the file src/conv.c. The manipulation of the argument src_length leads to uninitialized pointer. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. Upgrading to version 0.2.44 is able to address this issue. The patch is identified as 8def647eea27f7fd7ad33ff79c2d6d3e39948dce. It is recommended to upgrade the affected component. The code maintainer was informed beforehand about the issues. She reacted very fast and highly professional.(CVE-2025-2173)A vulnerability was found in libzvbi up to 0.2.43. It has been rated as problematic. Affected by this issue is the function _vbi_strndup_iconv. The manipulation leads to integer overflow. The attack may be launched remotely. The exploit has been disclosed to the public and may be used. Upgrading to version 0.2.44 is able to address this issue. It is recommended to upgrade the affected component. The code maintainer was informed beforehand about the issues. She reacted very fast and highly professional.(CVE-2025-2175)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="zvbi" release="1.oe2203sp4" version="0.2.44">
                         <filename>zvbi-0.2.44-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="zvbi-debuginfo" release="1.oe2203sp4" version="0.2.44">
                         <filename>zvbi-debuginfo-0.2.44-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="zvbi-debugsource" release="1.oe2203sp4" version="0.2.44">
                         <filename>zvbi-debugsource-0.2.44-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="zvbi-devel" release="1.oe2203sp4" version="0.2.44">
                         <filename>zvbi-devel-0.2.44-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="zvbi-help" release="1.oe2203sp4" version="0.2.44">
                         <filename>zvbi-help-0.2.44-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="zvbi" release="1.oe2203sp4" version="0.2.44">
                         <filename>zvbi-0.2.44-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="zvbi-debuginfo" release="1.oe2203sp4" version="0.2.44">
                         <filename>zvbi-debuginfo-0.2.44-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="zvbi-debugsource" release="1.oe2203sp4" version="0.2.44">
                         <filename>zvbi-debugsource-0.2.44-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="zvbi-devel" release="1.oe2203sp4" version="0.2.44">
                         <filename>zvbi-devel-0.2.44-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="zvbi-help" release="1.oe2203sp4" version="0.2.44">
                         <filename>zvbi-help-0.2.44-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1333</id>
          <title>An update for varnish is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-03-29"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30346" id="CVE-2025-30346" title="CVE-2025-30346" type="cve"></reference>
          </references>
          <description>Varnish Cache before 7.6.2 and Varnish Enterprise before 6.0.13r10 allow client-side desync via HTTP/1 requests.(CVE-2025-30346)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="varnish" release="2.oe2203sp4" version="7.4.3">
                         <filename>varnish-7.4.3-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="varnish-debuginfo" release="2.oe2203sp4" version="7.4.3">
                         <filename>varnish-debuginfo-7.4.3-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="varnish-debugsource" release="2.oe2203sp4" version="7.4.3">
                         <filename>varnish-debugsource-7.4.3-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="varnish-devel" release="2.oe2203sp4" version="7.4.3">
                         <filename>varnish-devel-7.4.3-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="varnish-help" release="2.oe2203sp4" version="7.4.3">
                         <filename>varnish-help-7.4.3-2.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="varnish" release="2.oe2203sp4" version="7.4.3">
                         <filename>varnish-7.4.3-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="varnish-debuginfo" release="2.oe2203sp4" version="7.4.3">
                         <filename>varnish-debuginfo-7.4.3-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="varnish-debugsource" release="2.oe2203sp4" version="7.4.3">
                         <filename>varnish-debugsource-7.4.3-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="varnish-devel" release="2.oe2203sp4" version="7.4.3">
                         <filename>varnish-devel-7.4.3-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1334</id>
          <title>An update for ed25519-java is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-03-29"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-36843" id="CVE-2020-36843" title="CVE-2020-36843" type="cve"></reference>
          </references>
          <description>The implementation of EdDSA in EdDSA-Java (aka ed25519-java) through 0.3.0 exhibits signature malleability and does not satisfy the SUF-CMA (Strong Existential Unforgeability under Chosen Message Attacks) property. This allows attackers to create new valid signatures different from previous signatures for a known message.(CVE-2020-36843)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="ed25519-java" release="5.oe2203sp4" version="0.3.0">
                         <filename>ed25519-java-0.3.0-5.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="ed25519-java-javadoc" release="5.oe2203sp4" version="0.3.0">
                         <filename>ed25519-java-javadoc-0.3.0-5.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1338</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-03-29"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49266" id="CVE-2022-49266" title="CVE-2022-49266" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49444" id="CVE-2022-49444" title="CVE-2022-49444" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49711" id="CVE-2022-49711" title="CVE-2022-49711" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:block: fix rq-qos breakage from skipping rq_qos_done_bio()a647a524a467 (&#34;block: don&#39;t call rq_qos_ops-&gt;done_bio if the bio isn&#39;ttracked&#34;) made bio_endio() skip rq_qos_done_bio() if BIO_TRACKED is not set.While this fixed a potential oops, it also broke blk-iocost by skipping thedone_bio callback for merged bios.Before, whether a bio goes through rq_qos_throttle() or rq_qos_merge(),rq_qos_done_bio() would be called on the bio on completion with BIO_TRACKEDdistinguishing the former from the latter. rq_qos_done_bio() is not calledfor bios which wenth through rq_qos_merge(). This royally confusesblk-iocost as the merged bios never finish and are considered perpetuallyin-flight.One reliably reproducible failure mode is an intermediate cgroup getingstuck active preventing its children from being activated due to theleaf-only rule, leading to loss of control. The following is fromresctl-bench protection scenario which emulates isolating a web server likeworkload from a memory bomb run on an iocost configuration which shouldyield a reasonable level of protection.  # cat /sys/block/nvme2n1/device/model  Samsung SSD 970 PRO 512GB  # cat /sys/fs/cgroup/io.cost.model  259:0 ctrl=user model=linear rbps=834913556 rseqiops=93622 rrandiops=102913 wbps=618985353 wseqiops=72325 wrandiops=71025  # cat /sys/fs/cgroup/io.cost.qos  259:0 enable=1 ctrl=user rpct=95.00 rlat=18776 wpct=95.00 wlat=8897 min=60.00 max=100.00  # resctl-bench -m 29.6G -r out.json run protection::scenario=mem-hog,loops=1  ...  Memory Hog Summary  ==================  IO Latency: R p50=242u:336u/2.5m p90=794u:1.4m/7.5m p99=2.7m:8.0m/62.5m max=8.0m:36.4m/350m              W p50=221u:323u/1.5m p90=709u:1.2m/5.5m p99=1.5m:2.5m/9.5m max=6.9m:35.9m/350m  Isolation and Request Latency Impact Distributions:                min   p01   p05   p10   p25   p50   p75   p90   p95   p99   max  mean stdev  isol%       15.90 15.90 15.90 40.05 57.24 59.07 60.01 74.63 74.63 90.35 90.35 58.12 15.82  lat-imp%        0     0     0     0     0  4.55 14.68 15.54 233.5 548.1 548.1 53.88 143.6  Result: isol=58.12:15.82% lat_imp=53.88%:143.6 work_csv=100.0% missing=3.96%The isolation result of 58.12% is close to what this device would showwithout any IO control.Fix it by introducing a new flag BIO_QOS_MERGED to mark merged bios andcalling rq_qos_done_bio() on them too. For consistency and clarity, renameBIO_TRACKED to BIO_QOS_THROTTLED. The flag checks are moved intorq_qos_done_bio() so that it&#39;s next to the code paths that set the flags.With the patch applied, the above same benchmark shows:  # resctl-bench -m 29.6G -r out.json run protection::scenario=mem-hog,loops=1  ...  Memory Hog Summary  ==================  IO Latency: R p50=123u:84.4u/985u p90=322u:256u/2.5m p99=1.6m:1.4m/9.5m max=11.1m:36.0m/350m              W p50=429u:274u/995u p90=1.7m:1.3m/4.5m p99=3.4m:2.7m/11.5m max=7.9m:5.9m/26.5m  Isolation and Request Latency Impact Distributions:                min   p01   p05   p10   p25   p50   p75   p90   p95   p99   max  mean stdev  isol%       84.91 84.91 89.51 90.73 92.31 94.49 96.36 98.04 98.71 100.0 100.0 94.42  2.81  lat-imp%        0     0     0     0     0  2.81  5.73 11.11 13.92 17.53 22.61  4.10  4.68  Result: isol=94.42:2.81% lat_imp=4.10%:4.68 work_csv=58.34% missing=0%(CVE-2022-49266)In the Linux kernel, the following vulnerability has been resolved:module: fix [e_shstrndx].sh_size=0 OOB accessIt is trivial to craft a module to trigger OOB access in this line:&#x9;if (info-&gt;secstrings[strhdr-&gt;sh_size - 1] != &#39;\0&#39;) {BUG: unable to handle page fault for address: ffffc90000aa0fffPGD 100000067 P4D 100000067 PUD 100066067 PMD 10436f067 PTE 0Oops: 0000 [#1] PREEMPT SMP PTICPU: 7 PID: 1215 Comm: insmod Not tainted 5.18.0-rc5-00007-g9bf578647087-dirty #10Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-4.fc34 04/01/2014RIP: 0010:load_module+0x19b/0x2391[rebased patch onto modules-next](CVE-2022-49444)In the Linux kernel, the following vulnerability has been resolved:bus: fsl-mc-bus: fix KASAN use-after-free in fsl_mc_bus_remove()In fsl_mc_bus_remove(), mc-&gt;root_mc_bus_dev-&gt;mc_io is passed tofsl_destroy_mc_io(). However, mc-&gt;root_mc_bus_dev is already freed infsl_mc_device_remove(). Then reference to mc-&gt;root_mc_bus_dev-&gt;mc_iotriggers KASAN use-after-free. To avoid the use-after-free, keep thereference to mc-&gt;root_mc_bus_dev-&gt;mc_io in a local variable and pass tofsl_destroy_mc_io().This patch needs rework to apply to kernels older than v5.15.(CVE-2022-49711)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="bpftool" release="257.0.0.160.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-257.0.0.160.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="257.0.0.160.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-257.0.0.160.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="257.0.0.160.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-257.0.0.160.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="257.0.0.160.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-257.0.0.160.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="257.0.0.160.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-257.0.0.160.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="257.0.0.160.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-257.0.0.160.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="257.0.0.160.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-257.0.0.160.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="257.0.0.160.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-257.0.0.160.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="257.0.0.160.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-257.0.0.160.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="257.0.0.160.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-257.0.0.160.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="257.0.0.160.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-257.0.0.160.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="257.0.0.160.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-257.0.0.160.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="257.0.0.160.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-257.0.0.160.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="257.0.0.160.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-257.0.0.160.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="257.0.0.160.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-257.0.0.160.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="257.0.0.160.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-257.0.0.160.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="257.0.0.160.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-257.0.0.160.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="257.0.0.160.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-257.0.0.160.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="257.0.0.160.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-257.0.0.160.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="257.0.0.160.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-257.0.0.160.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="257.0.0.160.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-257.0.0.160.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="257.0.0.160.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-257.0.0.160.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="257.0.0.160.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-257.0.0.160.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="257.0.0.160.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-257.0.0.160.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="257.0.0.160.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-257.0.0.160.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="257.0.0.160.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-257.0.0.160.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="257.0.0.160.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-257.0.0.160.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="257.0.0.160.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-257.0.0.160.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="257.0.0.160.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-257.0.0.160.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="257.0.0.160.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-257.0.0.160.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1341</id>
          <title>An update for dhcp is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-03-29"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-11187" id="CVE-2024-11187" title="CVE-2024-11187" type="cve"></reference>
          </references>
          <description>It is possible to construct a zone such that some queries to it will generate responses containing numerous records in the Additional section. An attacker sending many such queries can cause either the authoritative server itself or an independent resolver to use disproportionate resources processing the queries. Zones will usually need to have been deliberately crafted to attack this exposure.This issue affects BIND 9 versions 9.11.0 through 9.11.37, 9.16.0 through 9.16.50, 9.18.0 through 9.18.32, 9.20.0 through 9.20.4, 9.21.0 through 9.21.3, 9.11.3-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.50-S1, and 9.18.11-S1 through 9.18.32-S1.(CVE-2024-11187)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="12" arch="aarch64" name="dhcp" release="9.oe2203sp4" version="4.4.3">
                         <filename>dhcp-4.4.3-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="12" arch="aarch64" name="dhcp-debuginfo" release="9.oe2203sp4" version="4.4.3">
                         <filename>dhcp-debuginfo-4.4.3-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="12" arch="aarch64" name="dhcp-debugsource" release="9.oe2203sp4" version="4.4.3">
                         <filename>dhcp-debugsource-4.4.3-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="12" arch="aarch64" name="dhcp-devel" release="9.oe2203sp4" version="4.4.3">
                         <filename>dhcp-devel-4.4.3-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="12" arch="noarch" name="dhcp-help" release="9.oe2203sp4" version="4.4.3">
                         <filename>dhcp-help-4.4.3-9.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="12" arch="x86_64" name="dhcp" release="9.oe2203sp4" version="4.4.3">
                         <filename>dhcp-4.4.3-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="12" arch="x86_64" name="dhcp-debuginfo" release="9.oe2203sp4" version="4.4.3">
                         <filename>dhcp-debuginfo-4.4.3-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="12" arch="x86_64" name="dhcp-debugsource" release="9.oe2203sp4" version="4.4.3">
                         <filename>dhcp-debugsource-4.4.3-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="12" arch="x86_64" name="dhcp-devel" release="9.oe2203sp4" version="4.4.3">
                         <filename>dhcp-devel-4.4.3-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1345</id>
          <title>An update for arm-trusted-firmware is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-03-29"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-7881" id="CVE-2024-7881" title="CVE-2024-7881" type="cve"></reference>
          </references>
          <description>An unprivileged context can trigger a datamemory-dependent prefetch engine to fetch the contents of a privileged locationand consume those contents as an address that is also dereferenced.(CVE-2024-7881)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="arm-trusted-firmware-armv8" release="1.oe2203sp4" version="2.12.1">
                         <filename>arm-trusted-firmware-armv8-2.12.1-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1347</id>
          <title>An update for python-aiohttp is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-03-29"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-47627" id="CVE-2023-47627" title="CVE-2023-47627" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-49082" id="CVE-2023-49082" title="CVE-2023-49082" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-23829" id="CVE-2024-23829" title="CVE-2024-23829" type="cve"></reference>
          </references>
          <description>aiohttp is an asynchronous HTTP client/server framework for asyncio and Python. The HTTP parser in AIOHTTP has numerous problems with header parsing, which could lead to request smuggling. This parser is only used when AIOHTTP_NO_EXTENSIONS is enabled (or not using a prebuilt wheel). These bugs have been addressed in commit `d5c12ba89` which has been included in release version 3.8.6. Users are advised to upgrade. There are no known workarounds for these issues.(CVE-2023-47627)aiohttp is an asynchronous HTTP client/server framework for asyncio and Python. Improper validation makes it possible for an attacker to modify the HTTP request (e.g. insert a new header) or even create a new HTTP request if the attacker controls the HTTP method. The vulnerability occurs only if the attacker can control the HTTP method (GET, POST etc.) of the request. If the attacker can control the HTTP version of the request it will be able to modify the request (request smuggling). This issue has been patched in version 3.9.0.(CVE-2023-49082)aiohttp is an asynchronous HTTP client/server framework for asyncio and Python. Security-sensitive parts of the Python HTTP parser retained minor differences in allowable character sets, that must trigger error handling to robustly match frame boundaries of proxies in order to protect against injection of additional requests. Additionally, validation could trigger exceptions that were not handled consistently with processing of other malformed input.  Being more lenient than internet standards require could, depending on deployment environment, assist in request smuggling. The unhandled exception could cause excessive resource consumption on the application server and/or its logging facilities. This vulnerability exists due to an incomplete fix for CVE-2023-47627. Version 3.9.2 fixes this vulnerability.(CVE-2024-23829)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="python-aiohttp-debuginfo" release="6.oe2203sp4" version="3.7.4">
                         <filename>python-aiohttp-debuginfo-3.7.4-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python-aiohttp-debugsource" release="6.oe2203sp4" version="3.7.4">
                         <filename>python-aiohttp-debugsource-3.7.4-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python-aiohttp-help" release="6.oe2203sp4" version="3.7.4">
                         <filename>python-aiohttp-help-3.7.4-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-aiohttp" release="6.oe2203sp4" version="3.7.4">
                         <filename>python3-aiohttp-3.7.4-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python-aiohttp-debuginfo" release="6.oe2203sp4" version="3.7.4">
                         <filename>python-aiohttp-debuginfo-3.7.4-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python-aiohttp-debugsource" release="6.oe2203sp4" version="3.7.4">
                         <filename>python-aiohttp-debugsource-3.7.4-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python-aiohttp-help" release="6.oe2203sp4" version="3.7.4">
                         <filename>python-aiohttp-help-3.7.4-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-aiohttp" release="6.oe2203sp4" version="3.7.4">
                         <filename>python3-aiohttp-3.7.4-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1348</id>
          <title>An update for containerd is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-03-29"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40635" id="CVE-2024-40635" title="CVE-2024-40635" type="cve"></reference>
          </references>
          <description>containerd is an open-source container runtime. A bug was found in containerd prior to versions 1.6.38, 1.7.27, and 2.0.4 where containers launched with a User set as a `UID:GID` larger than the maximum 32-bit signed integer can cause an overflow condition where the container ultimately runs as root (UID 0). This could cause unexpected behavior for environments that require containers to run as a non-root user. This bug has been fixed in containerd 1.6.38, 1.7.27, and 2.04. As a workaround, ensure that only trusted images are used and that only trusted users have permissions to import images.(CVE-2024-40635)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="containerd" release="321.oe2203sp4" version="1.2.0">
                         <filename>containerd-1.2.0-321.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="containerd" release="321.oe2203sp4" version="1.2.0">
                         <filename>containerd-1.2.0-321.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1351</id>
          <title>An update for vim is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-03-29"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-29768" id="CVE-2025-29768" title="CVE-2025-29768" type="cve"></reference>
          </references>
          <description>Vim, a text editor, is vulnerable to potential data loss with zip.vim and special crafted zip files in versions prior to 9.1.1198. The impact is medium because a user must be made to view such an archive with Vim and then press &#39;x&#39; on such a strange filename. The issue has been fixed as of Vim patch v9.1.1198.(CVE-2025-29768)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="2" arch="aarch64" name="vim-X11" release="33.oe2203sp4" version="9.0">
                         <filename>vim-X11-9.0-33.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-common" release="33.oe2203sp4" version="9.0">
                         <filename>vim-common-9.0-33.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-debuginfo" release="33.oe2203sp4" version="9.0">
                         <filename>vim-debuginfo-9.0-33.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-debugsource" release="33.oe2203sp4" version="9.0">
                         <filename>vim-debugsource-9.0-33.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-enhanced" release="33.oe2203sp4" version="9.0">
                         <filename>vim-enhanced-9.0-33.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-minimal" release="33.oe2203sp4" version="9.0">
                         <filename>vim-minimal-9.0-33.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="noarch" name="vim-filesystem" release="33.oe2203sp4" version="9.0">
                         <filename>vim-filesystem-9.0-33.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-X11" release="33.oe2203sp4" version="9.0">
                         <filename>vim-X11-9.0-33.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-common" release="33.oe2203sp4" version="9.0">
                         <filename>vim-common-9.0-33.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-debuginfo" release="33.oe2203sp4" version="9.0">
                         <filename>vim-debuginfo-9.0-33.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-debugsource" release="33.oe2203sp4" version="9.0">
                         <filename>vim-debugsource-9.0-33.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-enhanced" release="33.oe2203sp4" version="9.0">
                         <filename>vim-enhanced-9.0-33.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-minimal" release="33.oe2203sp4" version="9.0">
                         <filename>vim-minimal-9.0-33.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1352</id>
          <title>An update for edk2 is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-04-03"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-9143" id="CVE-2024-9143" title="CVE-2024-9143" type="cve"></reference>
          </references>
          <description>Issue summary: Use of the low-level GF(2^m) elliptic curve APIs with untrustedexplicit values for the field polynomial can lead to out-of-bounds memory readsor writes.Impact summary: Out of bound memory writes can lead to an application crash oreven a possibility of a remote code execution, however, in all the protocolsinvolving Elliptic Curve Cryptography that we&#39;re aware of, either only &#34;namedcurves&#34; are supported, or, if explicit curve parameters are supported, theyspecify an X9.62 encoding of binary (GF(2^m)) curves that can&#39;t representproblematic input values. Thus the likelihood of existence of a vulnerableapplication is low.In particular, the X9.62 encoding is used for ECC keys in X.509 certificates,so problematic inputs cannot occur in the context of processing X.509certificates.  Any problematic use-cases would have to be using an &#34;exotic&#34;curve encoding.The affected APIs include: EC_GROUP_new_curve_GF2m(), EC_GROUP_new_from_params(),and various supporting BN_GF2m_*() functions.Applications working with &#34;exotic&#34; explicit binary (GF(2^m)) curve parameters,that make it possible to represent invalid field polynomials with a zeroconstant term, via the above or similar APIs, may terminate abruptly as aresult of reading or writing outside of array bounds.  Remote code executioncannot easily be ruled out.The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.(CVE-2024-9143)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="edk2-debuginfo" release="25.oe2203sp4" version="202011">
                         <filename>edk2-debuginfo-202011-25.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="edk2-debugsource" release="25.oe2203sp4" version="202011">
                         <filename>edk2-debugsource-202011-25.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="edk2-devel" release="25.oe2203sp4" version="202011">
                         <filename>edk2-devel-202011-25.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-aarch64" release="25.oe2203sp4" version="202011">
                         <filename>edk2-aarch64-202011-25.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-help" release="25.oe2203sp4" version="202011">
                         <filename>edk2-help-202011-25.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-ovmf" release="25.oe2203sp4" version="202011">
                         <filename>edk2-ovmf-202011-25.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-edk2-devel" release="25.oe2203sp4" version="202011">
                         <filename>python3-edk2-devel-202011-25.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-debuginfo" release="25.oe2203sp4" version="202011">
                         <filename>edk2-debuginfo-202011-25.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-debugsource" release="25.oe2203sp4" version="202011">
                         <filename>edk2-debugsource-202011-25.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-devel" release="25.oe2203sp4" version="202011">
                         <filename>edk2-devel-202011-25.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1358</id>
          <title>An update for ghostscript is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2025-04-03"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-27830" id="CVE-2025-27830" title="CVE-2025-27830" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-27832" id="CVE-2025-27832" title="CVE-2025-27832" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-27834" id="CVE-2025-27834" title="CVE-2025-27834" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-27835" id="CVE-2025-27835" title="CVE-2025-27835" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-27836" id="CVE-2025-27836" title="CVE-2025-27836" type="cve"></reference>
          </references>
          <description>An issue was discovered in Artifex Ghostscript before 10.05.0. A buffer overflow occurs during serialization of DollarBlend in a font, for base/write_t1.c and psi/zfapi.c.(CVE-2025-27830)An issue was discovered in Artifex Ghostscript before 10.05.0. The NPDL device has a Compression buffer overflow for contrib/japanese/gdevnpdl.c.(CVE-2025-27832)An issue was discovered in Artifex Ghostscript before 10.05.0. A buffer overflow occurs via an oversized Type 4 function in a PDF document to pdf/pdf_func.c.(CVE-2025-27834)An issue was discovered in Artifex Ghostscript before 10.05.0. A buffer overflow occurs when converting glyphs to Unicode in psi/zbfont.c.(CVE-2025-27835)An issue was discovered in Artifex Ghostscript before 10.05.0. The BJ10V device has a Print buffer overflow in contrib/japanese/gdev10v.c.(CVE-2025-27836)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="ghostscript" release="19.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-9.55.0-19.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ghostscript-debuginfo" release="19.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-debuginfo-9.55.0-19.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ghostscript-debugsource" release="19.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-debugsource-9.55.0-19.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ghostscript-devel" release="19.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-devel-9.55.0-19.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ghostscript-tools-dvipdf" release="19.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-tools-dvipdf-9.55.0-19.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="ghostscript-help" release="19.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-help-9.55.0-19.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript" release="19.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-9.55.0-19.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript-debuginfo" release="19.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-debuginfo-9.55.0-19.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript-debugsource" release="19.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-debugsource-9.55.0-19.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript-devel" release="19.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-devel-9.55.0-19.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript-tools-dvipdf" release="19.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-tools-dvipdf-9.55.0-19.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1365</id>
          <title>An update for corosync is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2025-04-03"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30472" id="CVE-2025-30472" title="CVE-2025-30472" type="cve"></reference>
          </references>
          <description>Corosync through 3.1.9, if encryption is disabled or the attacker knows the encryption key, has a stack-based buffer overflow in orf_token_endian_convert in exec/totemsrp.c via a large UDP packet.(CVE-2025-30472)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="corosync" release="2.oe2203sp4" version="3.1.5">
                         <filename>corosync-3.1.5-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="corosync-debuginfo" release="2.oe2203sp4" version="3.1.5">
                         <filename>corosync-debuginfo-3.1.5-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="corosync-debugsource" release="2.oe2203sp4" version="3.1.5">
                         <filename>corosync-debugsource-3.1.5-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="corosync-vqsim" release="2.oe2203sp4" version="3.1.5">
                         <filename>corosync-vqsim-3.1.5-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="corosynclib" release="2.oe2203sp4" version="3.1.5">
                         <filename>corosynclib-3.1.5-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="corosynclib-devel" release="2.oe2203sp4" version="3.1.5">
                         <filename>corosynclib-devel-3.1.5-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="corosync" release="2.oe2203sp4" version="3.1.5">
                         <filename>corosync-3.1.5-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="corosync-debuginfo" release="2.oe2203sp4" version="3.1.5">
                         <filename>corosync-debuginfo-3.1.5-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="corosync-debugsource" release="2.oe2203sp4" version="3.1.5">
                         <filename>corosync-debugsource-3.1.5-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="corosync-vqsim" release="2.oe2203sp4" version="3.1.5">
                         <filename>corosync-vqsim-3.1.5-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="corosynclib" release="2.oe2203sp4" version="3.1.5">
                         <filename>corosynclib-3.1.5-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="corosynclib-devel" release="2.oe2203sp4" version="3.1.5">
                         <filename>corosynclib-devel-3.1.5-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1369</id>
          <title>An update for libtheora is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2025-04-03"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56431" id="CVE-2024-56431" title="CVE-2024-56431" type="cve"></reference>
          </references>
          <description>oc_huff_tree_unpack in huffdec.c in libtheora in Theora through 1.0 7180717 has an invalid negative left shift.(CVE-2024-56431)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="libtheora" release="26.oe2203sp4" version="1.1.1">
                         <filename>libtheora-1.1.1-26.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="libtheora-debuginfo" release="26.oe2203sp4" version="1.1.1">
                         <filename>libtheora-debuginfo-1.1.1-26.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="libtheora-debugsource" release="26.oe2203sp4" version="1.1.1">
                         <filename>libtheora-debugsource-1.1.1-26.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="libtheora-devel" release="26.oe2203sp4" version="1.1.1">
                         <filename>libtheora-devel-1.1.1-26.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="theora-tools" release="26.oe2203sp4" version="1.1.1">
                         <filename>theora-tools-1.1.1-26.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="libtheora-help" release="26.oe2203sp4" version="1.1.1">
                         <filename>libtheora-help-1.1.1-26.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="libtheora" release="26.oe2203sp4" version="1.1.1">
                         <filename>libtheora-1.1.1-26.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="libtheora-debuginfo" release="26.oe2203sp4" version="1.1.1">
                         <filename>libtheora-debuginfo-1.1.1-26.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="libtheora-debugsource" release="26.oe2203sp4" version="1.1.1">
                         <filename>libtheora-debugsource-1.1.1-26.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="libtheora-devel" release="26.oe2203sp4" version="1.1.1">
                         <filename>libtheora-devel-1.1.1-26.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="theora-tools" release="26.oe2203sp4" version="1.1.1">
                         <filename>theora-tools-1.1.1-26.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1377</id>
          <title>An update for firefox is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2025-04-03"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32216" id="CVE-2023-32216" title="CVE-2023-32216" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6879" id="CVE-2023-6879" title="CVE-2023-6879" type="cve"></reference>
          </references>
          <description>Memory safety  bugs present in Firefox 112. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 113.(CVE-2023-32216)Increasing the resolution of video frames, while performing a multi-threaded encode, can result in a heap overflow in av1_loop_restoration_dealloc().(CVE-2023-6879)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="firefox" release="1.oe2203sp4" version="128.8.0">
                         <filename>firefox-128.8.0-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="firefox-debuginfo" release="1.oe2203sp4" version="128.8.0">
                         <filename>firefox-debuginfo-128.8.0-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="firefox-debugsource" release="1.oe2203sp4" version="128.8.0">
                         <filename>firefox-debugsource-128.8.0-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox" release="1.oe2203sp4" version="128.8.0">
                         <filename>firefox-128.8.0-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox-debuginfo" release="1.oe2203sp4" version="128.8.0">
                         <filename>firefox-debuginfo-128.8.0-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox-debugsource" release="1.oe2203sp4" version="128.8.0">
                         <filename>firefox-debugsource-128.8.0-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1383</id>
          <title>An update for giflib is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-04-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-31344" id="CVE-2025-31344" title="CVE-2025-31344" type="cve"></reference>
          </references>
          <description>openeuler社区开源软件giflib存在堆缓冲区溢出漏洞，通过未gif2rgb构造异常输入，造成内存越界读(CVE-2025-31344)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="giflib" release="2.oe2203sp4" version="5.2.2">
                         <filename>giflib-5.2.2-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="giflib-devel" release="2.oe2203sp4" version="5.2.2">
                         <filename>giflib-devel-5.2.2-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="giflib-utils" release="2.oe2203sp4" version="5.2.2">
                         <filename>giflib-utils-5.2.2-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="giflib-help" release="2.oe2203sp4" version="5.2.2">
                         <filename>giflib-help-5.2.2-2.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="giflib" release="2.oe2203sp4" version="5.2.2">
                         <filename>giflib-5.2.2-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="giflib-devel" release="2.oe2203sp4" version="5.2.2">
                         <filename>giflib-devel-5.2.2-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="giflib-utils" release="2.oe2203sp4" version="5.2.2">
                         <filename>giflib-utils-5.2.2-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1385</id>
          <title>An update for qt5-qtbase is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-04-11"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30348" id="CVE-2025-30348" title="CVE-2025-30348" type="cve"></reference>
          </references>
          <description>encodeText in QDom in Qt before 6.8.0 has a complex algorithm involving XML string copy and inline replacement of parts of a string (with relocation of later data).(CVE-2025-30348)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="qt5-qtbase" release="17.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtbase-5.15.2-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-debuginfo" release="17.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtbase-debuginfo-5.15.2-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-debugsource" release="17.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtbase-debugsource-5.15.2-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-devel" release="17.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtbase-devel-5.15.2-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-examples" release="17.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtbase-examples-5.15.2-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-gui" release="17.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtbase-gui-5.15.2-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-mysql" release="17.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtbase-mysql-5.15.2-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-odbc" release="17.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtbase-odbc-5.15.2-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-postgresql" release="17.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtbase-postgresql-5.15.2-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-private-devel" release="17.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtbase-private-devel-5.15.2-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-static" release="17.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtbase-static-5.15.2-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="qt5-qtbase-common" release="17.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtbase-common-5.15.2-17.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase" release="17.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtbase-5.15.2-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-debuginfo" release="17.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtbase-debuginfo-5.15.2-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-debugsource" release="17.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtbase-debugsource-5.15.2-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-devel" release="17.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtbase-devel-5.15.2-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-examples" release="17.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtbase-examples-5.15.2-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-gui" release="17.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtbase-gui-5.15.2-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-mysql" release="17.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtbase-mysql-5.15.2-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-odbc" release="17.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtbase-odbc-5.15.2-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-postgresql" release="17.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtbase-postgresql-5.15.2-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-private-devel" release="17.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtbase-private-devel-5.15.2-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-static" release="17.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtbase-static-5.15.2-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1390</id>
          <title>An update for poppler is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-04-11"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-32364" id="CVE-2025-32364" title="CVE-2025-32364" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-32365" id="CVE-2025-32365" title="CVE-2025-32365" type="cve"></reference>
          </references>
          <description>A floating-point exception in the PSStack::roll function of Poppler before 25.04.0 can cause an application to crash when handling malformed inputs associated with INT_MIN.(CVE-2025-32364)Poppler before 25.04.0 allows crafted input files to trigger out-of-bounds reads in the JBIG2Bitmap::combine function in JBIG2Stream.cc because of a misplaced isOk check.(CVE-2025-32365)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="poppler" release="11.oe2203sp4" version="0.90.0">
                         <filename>poppler-0.90.0-11.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-cpp" release="11.oe2203sp4" version="0.90.0">
                         <filename>poppler-cpp-0.90.0-11.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-cpp-devel" release="11.oe2203sp4" version="0.90.0">
                         <filename>poppler-cpp-devel-0.90.0-11.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-debuginfo" release="11.oe2203sp4" version="0.90.0">
                         <filename>poppler-debuginfo-0.90.0-11.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-debugsource" release="11.oe2203sp4" version="0.90.0">
                         <filename>poppler-debugsource-0.90.0-11.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-devel" release="11.oe2203sp4" version="0.90.0">
                         <filename>poppler-devel-0.90.0-11.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-glib" release="11.oe2203sp4" version="0.90.0">
                         <filename>poppler-glib-0.90.0-11.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-glib-devel" release="11.oe2203sp4" version="0.90.0">
                         <filename>poppler-glib-devel-0.90.0-11.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-qt5" release="11.oe2203sp4" version="0.90.0">
                         <filename>poppler-qt5-0.90.0-11.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-qt5-devel" release="11.oe2203sp4" version="0.90.0">
                         <filename>poppler-qt5-devel-0.90.0-11.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-utils" release="11.oe2203sp4" version="0.90.0">
                         <filename>poppler-utils-0.90.0-11.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="poppler-glib-doc" release="11.oe2203sp4" version="0.90.0">
                         <filename>poppler-glib-doc-0.90.0-11.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="poppler-help" release="11.oe2203sp4" version="0.90.0">
                         <filename>poppler-help-0.90.0-11.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler" release="11.oe2203sp4" version="0.90.0">
                         <filename>poppler-0.90.0-11.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-cpp" release="11.oe2203sp4" version="0.90.0">
                         <filename>poppler-cpp-0.90.0-11.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-cpp-devel" release="11.oe2203sp4" version="0.90.0">
                         <filename>poppler-cpp-devel-0.90.0-11.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-debuginfo" release="11.oe2203sp4" version="0.90.0">
                         <filename>poppler-debuginfo-0.90.0-11.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-debugsource" release="11.oe2203sp4" version="0.90.0">
                         <filename>poppler-debugsource-0.90.0-11.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-devel" release="11.oe2203sp4" version="0.90.0">
                         <filename>poppler-devel-0.90.0-11.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-glib" release="11.oe2203sp4" version="0.90.0">
                         <filename>poppler-glib-0.90.0-11.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-glib-devel" release="11.oe2203sp4" version="0.90.0">
                         <filename>poppler-glib-devel-0.90.0-11.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-qt5" release="11.oe2203sp4" version="0.90.0">
                         <filename>poppler-qt5-0.90.0-11.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-qt5-devel" release="11.oe2203sp4" version="0.90.0">
                         <filename>poppler-qt5-devel-0.90.0-11.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-utils" release="11.oe2203sp4" version="0.90.0">
                         <filename>poppler-utils-0.90.0-11.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1393</id>
          <title>An update for ansible is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-04-11"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5764" id="CVE-2023-5764" title="CVE-2023-5764" type="cve"></reference>
          </references>
          <description>A template injection flaw was found in Ansible where a user&#39;s controller internal templating operations may remove the unsafe designation from template data. This issue could allow an attacker to use a specially crafted file to introduce templating injection when supplying templating data.(CVE-2023-5764)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="ansible" release="7.oe2203sp4" version="2.9.27">
                         <filename>ansible-2.9.27-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="ansible-help" release="7.oe2203sp4" version="2.9.27">
                         <filename>ansible-help-2.9.27-7.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1399</id>
          <title>An update for ghostscript is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2025-04-11"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-27831" id="CVE-2025-27831" title="CVE-2025-27831" type="cve"></reference>
          </references>
          <description>An issue was discovered in Artifex Ghostscript before 10.05.0. The DOCXWRITE TXTWRITE device has a text buffer overflow via long characters to devices/vector/doc_common.c.(CVE-2025-27831)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="ghostscript" release="20.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-9.55.0-20.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ghostscript-debuginfo" release="20.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-debuginfo-9.55.0-20.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ghostscript-debugsource" release="20.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-debugsource-9.55.0-20.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ghostscript-devel" release="20.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-devel-9.55.0-20.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ghostscript-tools-dvipdf" release="20.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-tools-dvipdf-9.55.0-20.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="ghostscript-help" release="20.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-help-9.55.0-20.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript" release="20.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-9.55.0-20.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript-debuginfo" release="20.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-debuginfo-9.55.0-20.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript-debugsource" release="20.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-debugsource-9.55.0-20.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript-devel" release="20.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-devel-9.55.0-20.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript-tools-dvipdf" release="20.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-tools-dvipdf-9.55.0-20.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1403</id>
          <title>An update for assimp is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-04-11"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-3015" id="CVE-2025-3015" title="CVE-2025-3015" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-3016" id="CVE-2025-3016" title="CVE-2025-3016" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-3159" id="CVE-2025-3159" title="CVE-2025-3159" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-3160" id="CVE-2025-3160" title="CVE-2025-3160" type="cve"></reference>
          </references>
          <description>A vulnerability classified as critical has been found in Open Asset Import Library Assimp 5.4.3. This affects the function Assimp::ASEImporter::BuildUniqueRepresentation of the file code/AssetLib/ASE/ASELoader.cpp of the component ASE File Handler. The manipulation of the argument mIndices leads to out-of-bounds read. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used. Upgrading to version 6.0 is able to address this issue. The patch is named 7c705fde418d68cca4e8eff56be01b2617b0d6fe. It is recommended to apply a patch to fix this issue.(CVE-2025-3015)A vulnerability classified as problematic was found in Open Asset Import Library Assimp 5.4.3. This vulnerability affects the function Assimp::MDLImporter::ParseTextureColorData of the file code/AssetLib/MDL/MDLMaterialLoader.cpp of the component MDL File Handler. The manipulation of the argument mWidth/mHeight leads to resource consumption. The attack can be initiated remotely. Upgrading to version 6.0 is able to address this issue. The name of the patch is 5d2a7482312db2e866439a8c05a07ce1e718bed1. It is recommended to apply a patch to fix this issue.(CVE-2025-3016)A vulnerability, which was classified as critical, was found in Open Asset Import Library Assimp 5.4.3. This affects the function Assimp::ASE::Parser::ParseLV4MeshBonesVertices of the file code/AssetLib/ASE/ASEParser.cpp of the component ASE File Handler. The manipulation leads to heap-based buffer overflow. The attack needs to be approached locally. The exploit has been disclosed to the public and may be used. The identifier of the patch is e8a6286542924e628e02749c4f5ac4f91fdae71b. It is recommended to apply a patch to fix this issue.(CVE-2025-3159)A vulnerability has been found in Open Asset Import Library Assimp 5.4.3 and classified as problematic. This vulnerability affects the function Assimp::SceneCombiner::AddNodeHashes of the file code/Common/SceneCombiner.cpp of the component File Handler. The manipulation leads to out-of-bounds read. An attack has to be approached locally. The exploit has been disclosed to the public and may be used. The patch is identified as a0993658f40d8e13ff5823990c30b43c82a5daf0. It is recommended to apply a patch to fix this issue.(CVE-2025-3160)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="assimp" release="7.oe2203sp4" version="5.2.4">
                         <filename>assimp-5.2.4-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="assimp-debuginfo" release="7.oe2203sp4" version="5.2.4">
                         <filename>assimp-debuginfo-5.2.4-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="assimp-debugsource" release="7.oe2203sp4" version="5.2.4">
                         <filename>assimp-debugsource-5.2.4-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="assimp-devel" release="7.oe2203sp4" version="5.2.4">
                         <filename>assimp-devel-5.2.4-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="assimp-help" release="7.oe2203sp4" version="5.2.4">
                         <filename>assimp-help-5.2.4-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-assimp" release="7.oe2203sp4" version="5.2.4">
                         <filename>python3-assimp-5.2.4-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="assimp" release="7.oe2203sp4" version="5.2.4">
                         <filename>assimp-5.2.4-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="assimp-debuginfo" release="7.oe2203sp4" version="5.2.4">
                         <filename>assimp-debuginfo-5.2.4-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="assimp-debugsource" release="7.oe2203sp4" version="5.2.4">
                         <filename>assimp-debugsource-5.2.4-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="assimp-devel" release="7.oe2203sp4" version="5.2.4">
                         <filename>assimp-devel-5.2.4-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1406</id>
          <title>An update for transfig is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-04-11"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-31162" id="CVE-2025-31162" title="CVE-2025-31162" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-31163" id="CVE-2025-31163" title="CVE-2025-31163" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-31164" id="CVE-2025-31164" title="CVE-2025-31164" type="cve"></reference>
          </references>
          <description>Floating point exception in fig2dev in version 3.2.9a allows an attacker to availability via local input manipulation via get_slope function.(CVE-2025-31162)Segmentation fault in fig2dev in version 3.2.9a allows an attacker to availability via local input manipulation via put_patternarc function.(CVE-2025-31163)heap-buffer overflow in fig2dev in version 3.2.9a allows an attacker to availability via local input manipulation via  create_line_with_spline.(CVE-2025-31164)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="transfig" release="3.oe2203sp4" version="3.2.8b">
                         <filename>transfig-3.2.8b-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="transfig-debuginfo" release="3.oe2203sp4" version="3.2.8b">
                         <filename>transfig-debuginfo-3.2.8b-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="transfig-debugsource" release="3.oe2203sp4" version="3.2.8b">
                         <filename>transfig-debugsource-3.2.8b-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="transfig-help" release="3.oe2203sp4" version="3.2.8b">
                         <filename>transfig-help-3.2.8b-3.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="transfig" release="3.oe2203sp4" version="3.2.8b">
                         <filename>transfig-3.2.8b-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="transfig-debuginfo" release="3.oe2203sp4" version="3.2.8b">
                         <filename>transfig-debuginfo-3.2.8b-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="transfig-debugsource" release="3.oe2203sp4" version="3.2.8b">
                         <filename>transfig-debugsource-3.2.8b-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1410</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-04-11"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47660" id="CVE-2021-47660" title="CVE-2021-47660" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49443" id="CVE-2022-49443" title="CVE-2022-49443" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49513" id="CVE-2022-49513" title="CVE-2022-49513" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49553" id="CVE-2022-49553" title="CVE-2022-49553" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53001" id="CVE-2023-53001" title="CVE-2023-53001" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56642" id="CVE-2024-56642" title="CVE-2024-56642" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56664" id="CVE-2024-56664" title="CVE-2024-56664" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57951" id="CVE-2024-57951" title="CVE-2024-57951" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-58055" id="CVE-2024-58055" title="CVE-2024-58055" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21715" id="CVE-2025-21715" title="CVE-2025-21715" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21718" id="CVE-2025-21718" title="CVE-2025-21718" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21722" id="CVE-2025-21722" title="CVE-2025-21722" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21726" id="CVE-2025-21726" title="CVE-2025-21726" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21727" id="CVE-2025-21727" title="CVE-2025-21727" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21785" id="CVE-2025-21785" title="CVE-2025-21785" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21791" id="CVE-2025-21791" title="CVE-2025-21791" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21804" id="CVE-2025-21804" title="CVE-2025-21804" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21816" id="CVE-2025-21816" title="CVE-2025-21816" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21823" id="CVE-2025-21823" title="CVE-2025-21823" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21863" id="CVE-2025-21863" title="CVE-2025-21863" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21881" id="CVE-2025-21881" title="CVE-2025-21881" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21887" id="CVE-2025-21887" title="CVE-2025-21887" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21943" id="CVE-2025-21943" title="CVE-2025-21943" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:fs/ntfs3: Fix some memory leaks in an error handling path of &#39;log_replay()&#39;All error handling paths lead to &#39;out&#39; where many resources are freed.Do it as well here instead of a direct return, otherwise &#39;log&#39;, &#39;ra&#39; and&#39;log-&gt;one_page_buf&#39; (at least) will leak.(CVE-2021-47660)In the Linux kernel, the following vulnerability has been resolved:list: fix a data-race around ep-&gt;rdllistep_poll() first calls ep_events_available() with no lock held and checksif ep-&gt;rdllist is empty by list_empty_careful(), which readsrdllist-&gt;prev.  Thus all accesses to it need some protection to avoidstore/load-tearing.Note INIT_LIST_HEAD_RCU() already has the annotation for both prevand next.Commit bf3b9f6372c4 (&#34;epoll: Add busy poll support to epoll with socketfds.&#34;) added the first lockless ep_events_available(), and commitc5a282e9635e (&#34;fs/epoll: reduce the scope of wq lock in epoll_wait()&#34;)made some ep_events_available() calls lockless and added single call undera lock, finally commit e59d3c64cba6 (&#34;epoll: eliminate unnecessary lockfor zero timeout&#34;) made the last ep_events_available() lockless.BUG: KCSAN: data-race in do_epoll_wait / do_epoll_waitwrite to 0xffff88810480c7d8 of 8 bytes by task 1802 on cpu 0: INIT_LIST_HEAD include/linux/list.h:38 [inline] list_splice_init include/linux/list.h:492 [inline] ep_start_scan fs/eventpoll.c:622 [inline] ep_send_events fs/eventpoll.c:1656 [inline] ep_poll fs/eventpoll.c:1806 [inline] do_epoll_wait+0x4eb/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xaeread to 0xffff88810480c7d8 of 8 bytes by task 1799 on cpu 1: list_empty_careful include/linux/list.h:329 [inline] ep_events_available fs/eventpoll.c:381 [inline] ep_poll fs/eventpoll.c:1797 [inline] do_epoll_wait+0x279/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xaevalue changed: 0xffff88810480c7d0 -&gt; 0xffff888103c15098Reported by Kernel Concurrency Sanitizer on:CPU: 1 PID: 1799 Comm: syz-fuzzer Tainted: G        W         5.17.0-rc7-syzkaller-dirty #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011(CVE-2022-49443)In the Linux kernel, the following vulnerability has been resolved:cpufreq: governor: Use kobject release() method to free dbs_dataThe struct dbs_data embeds a struct gov_attr_set andthe struct gov_attr_set embeds a kobject. Since every kobject must havea release() method and we can&#39;t use kfree() to free it directly,so introduce cpufreq_dbs_data_release() to release the dbs_data viathe kobject::release() method. This fixes the calltrace like below:  ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x34  WARNING: CPU: 12 PID: 810 at lib/debugobjects.c:505 debug_print_object+0xb8/0x100  Modules linked in:  CPU: 12 PID: 810 Comm: sh Not tainted 5.16.0-next-20220120-yocto-standard+ #536  Hardware name: Marvell OcteonTX CN96XX board (DT)  pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)  pc : debug_print_object+0xb8/0x100  lr : debug_print_object+0xb8/0x100  sp : ffff80001dfcf9a0  x29: ffff80001dfcf9a0 x28: 0000000000000001 x27: ffff0001464f0000  x26: 0000000000000000 x25: ffff8000090e3f00 x24: ffff80000af60210  x23: ffff8000094dfb78 x22: ffff8000090e3f00 x21: ffff0001080b7118  x20: ffff80000aeb2430 x19: ffff800009e8f5e0 x18: 0000000000000000  x17: 0000000000000002 x16: 00004d62e58be040 x15: 013590470523aff8  x14: ffff8000090e1828 x13: 0000000001359047 x12: 00000000f5257d14  x11: 0000000000040591 x10: 0000000066c1ffea x9 : ffff8000080d15e0  x8 : ffff80000a1765a8 x7 : 0000000000000000 x6 : 0000000000000001  x5 : ffff800009e8c000 x4 : ffff800009e8c760 x3 : 0000000000000000  x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0001474ed040  Call trace:   debug_print_object+0xb8/0x100   __debug_check_no_obj_freed+0x1d0/0x25c   debug_check_no_obj_freed+0x24/0xa0   kfree+0x11c/0x440   cpufreq_dbs_governor_exit+0xa8/0xac   cpufreq_exit_governor+0x44/0x90   cpufreq_set_policy+0x29c/0x570   store_scaling_governor+0x110/0x154   store+0xb0/0xe0   sysfs_kf_write+0x58/0x84   kernfs_fop_write_iter+0x12c/0x1c0   new_sync_write+0xf0/0x18c   vfs_write+0x1cc/0x220   ksys_write+0x74/0x100   __arm64_sys_write+0x28/0x3c   invoke_syscall.constprop.0+0x58/0xf0   do_el0_svc+0x70/0x170   el0_svc+0x54/0x190   el0t_64_sync_handler+0xa4/0x130   el0t_64_sync+0x1a0/0x1a4  irq event stamp: 189006  hardirqs last  enabled at (189005): [&lt;ffff8000080849d0&gt;] finish_task_switch.isra.0+0xe0/0x2c0  hardirqs last disabled at (189006): [&lt;ffff8000090667a4&gt;] el1_dbg+0x24/0xa0  softirqs last  enabled at (188966): [&lt;ffff8000080106d0&gt;] __do_softirq+0x4b0/0x6a0  softirqs last disabled at (188957): [&lt;ffff80000804a618&gt;] __irq_exit_rcu+0x108/0x1a4[ rjw: Because can be freed by the gov_attr_set_put() in  cpufreq_dbs_governor_exit() now, it is also necessary to put the  invocation of the governor -&gt;exit() callback into the new  cpufreq_dbs_data_release() function. ](CVE-2022-49513)In the Linux kernel, the following vulnerability has been resolved:fs/ntfs3: validate BOOT sectors_per_clustersWhen the NTFS BOOT sectors_per_clusters field is &gt; 0x80, it represents ashift value.  Make sure that the shift value is not too large before usingit (NTFS max cluster size is 2MB).  Return -EVINVAL if it too large.This prevents negative shift values and shift values that are larger thanthe field size.Prevents this UBSAN error: UBSAN: shift-out-of-bounds in ../fs/ntfs3/super.c:673:16 shift exponent -192 is negative(CVE-2022-49553)In the Linux kernel, the following vulnerability has been resolved:drm/drm_vma_manager: Add drm_vma_node_allow_once()Currently there is no easy way for a drm driver to safely check and allowdrm_vma_offset_node for a drm file just once. Allow drm drivers to callnon-refcounted version of drm_vma_node_allow() so that a driver doesn&#39;tneed to keep track of each drm_vma_node_allow() to call subsequentdrm_vma_node_revoke() to prevent memory leak.(CVE-2023-53001)In the Linux kernel, the following vulnerability has been resolved:tipc: Fix use-after-free of kernel socket in cleanup_bearer().syzkaller reported a use-after-free of UDP kernel socketin cleanup_bearer() without repro. [0][1]When bearer_disable() calls tipc_udp_disable(), cleanupof the UDP kernel socket is deferred by work callingcleanup_bearer().tipc_exit_net() waits for such works to finish by checkingtipc_net(net)-&gt;wq_count.  However, the work decrements thecount too early before releasing the kernel socket,unblocking cleanup_net() and resulting in use-after-free.Let&#39;s move the decrement after releasing the socket incleanup_bearer().[0]:ref_tracker: net notrefcnt@000000009b3d1faf has 1/1 users at     sk_alloc+0x438/0x608     inet_create+0x4c8/0xcb0     __sock_create+0x350/0x6b8     sock_create_kern+0x58/0x78     udp_sock_create4+0x68/0x398     udp_sock_create+0x88/0xc8     tipc_udp_enable+0x5e8/0x848     __tipc_nl_bearer_enable+0x84c/0xed8     tipc_nl_bearer_enable+0x38/0x60     genl_family_rcv_msg_doit+0x170/0x248     genl_rcv_msg+0x400/0x5b0     netlink_rcv_skb+0x1dc/0x398     genl_rcv+0x44/0x68     netlink_unicast+0x678/0x8b0     netlink_sendmsg+0x5e4/0x898     ____sys_sendmsg+0x500/0x830[1]:BUG: KMSAN: use-after-free in udp_hashslot include/net/udp.h:85 [inline]BUG: KMSAN: use-after-free in udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979 udp_hashslot include/net/udp.h:85 [inline] udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979 sk_common_release+0xaf/0x3f0 net/core/sock.c:3820 inet_release+0x1e0/0x260 net/ipv4/af_inet.c:437 inet6_release+0x6f/0xd0 net/ipv6/af_inet6.c:489 __sock_release net/socket.c:658 [inline] sock_release+0xa0/0x210 net/socket.c:686 cleanup_bearer+0x42d/0x4c0 net/tipc/udp_media.c:819 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310 worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391 kthread+0x531/0x6b0 kernel/kthread.c:389 ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244Uninit was created at: slab_free_hook mm/slub.c:2269 [inline] slab_free mm/slub.c:4580 [inline] kmem_cache_free+0x207/0xc40 mm/slub.c:4682 net_free net/core/net_namespace.c:454 [inline] cleanup_net+0x16f2/0x19d0 net/core/net_namespace.c:647 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310 worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391 kthread+0x531/0x6b0 kernel/kthread.c:389 ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244CPU: 0 UID: 0 PID: 54 Comm: kworker/0:2 Not tainted 6.12.0-rc1-00131-gf66ebf37d69c #7 91723d6f74857f70725e1583cba3cf4adc716cfaHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014Workqueue: events cleanup_bearer(CVE-2024-56642)In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Fix race between element replace and close()Element replace (with a socket different from the one stored) may racewith socket&#39;s close() link popping &amp; unlinking. __sock_map_delete()unconditionally unrefs the (wrong) element:// set map[0] = s0map_update_elem(map, 0, s0)// drop fd of s0close(s0)  sock_map_close()    lock_sock(sk)               (s0!)    sock_map_remove_links(sk)      link = sk_psock_link_pop()      sock_map_unlink(sk, link)        sock_map_delete_from_link                                        // replace map[0] with s1                                        map_update_elem(map, 0, s1)                                          sock_map_update_elem                                (s1!)       lock_sock(sk)                                            sock_map_update_common                                              psock = sk_psock(sk)                                              spin_lock(&amp;stab-&gt;lock)                                              osk = stab-&gt;sks[idx]                                              sock_map_add_link(..., &amp;stab-&gt;sks[idx])                                              sock_map_unref(osk, &amp;stab-&gt;sks[idx])                                                psock = sk_psock(osk)                                                sk_psock_put(sk, psock)                                                  if (refcount_dec_and_test(&amp;psock))                                                    sk_psock_drop(sk, psock)                                              spin_unlock(&amp;stab-&gt;lock)                                            unlock_sock(sk)          __sock_map_delete            spin_lock(&amp;stab-&gt;lock)            sk = *psk                        // s1 replaced s0; sk == s1            if (!sk_test || sk_test == sk)   // sk_test (s0) != sk (s1); no branch              sk = xchg(psk, NULL)            if (sk)              sock_map_unref(sk, psk)        // unref s1; sks[idx] will dangle                psock = sk_psock(sk)                sk_psock_put(sk, psock)                  if (refcount_dec_and_test())                    sk_psock_drop(sk, psock)            spin_unlock(&amp;stab-&gt;lock)    release_sock(sk)Then close(map) enqueues bpf_map_free_deferred, which finally callssock_map_free(). This results in some refcount_t warnings along witha KASAN splat [1].Fix __sock_map_delete(), do not allow sock_map_unref() on elements thatmay have been replaced.[1]:BUG: KASAN: slab-use-after-free in sock_map_free+0x10e/0x330Write of size 4 at addr ffff88811f5b9100 by task kworker/u64:12/1063CPU: 14 UID: 0 PID: 1063 Comm: kworker/u64:12 Not tainted 6.12.0+ #125Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014Workqueue: events_unbound bpf_map_free_deferredCall Trace: &lt;TASK&gt; dump_stack_lvl+0x68/0x90 print_report+0x174/0x4f6 kasan_report+0xb9/0x190 kasan_check_range+0x10f/0x1e0 sock_map_free+0x10e/0x330 bpf_map_free_deferred+0x173/0x320 process_one_work+0x846/0x1420 worker_thread+0x5b3/0xf80 kthread+0x29e/0x360 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x1a/0x30 &lt;/TASK&gt;Allocated by task 1202: kasan_save_stack+0x1e/0x40 kasan_save_track+0x10/0x30 __kasan_slab_alloc+0x85/0x90 kmem_cache_alloc_noprof+0x131/0x450 sk_prot_alloc+0x5b/0x220 sk_alloc+0x2c/0x870 unix_create1+0x88/0x8a0 unix_create+0xc5/0x180 __sock_create+0x241/0x650 __sys_socketpair+0x1ce/0x420 __x64_sys_socketpair+0x92/0x100 do_syscall_64+0x93/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7eFreed by task 46: kasan_save_stack+0x1e/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x60 __kasan_slab_free+0x4b/0x70 kmem_cache_free+0x1a1/0x590 __sk_destruct+0x388/0x5a0 sk_psock_destroy+0x73e/0xa50 process_one_work+0x846/0x1420 worker_thread+0x5b3/0xf80 kthread+0x29e/0x360 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x1a/0x30The bu---truncated---(CVE-2024-56664)In the Linux kernel, the following vulnerability has been resolved:hrtimers: Handle CPU state correctly on hotplugConsider a scenario where a CPU transitions from CPUHP_ONLINE to halfwaythrough a CPU hotunplug down to CPUHP_HRTIMERS_PREPARE, and then back toCPUHP_ONLINE:Since hrtimers_prepare_cpu() does not run, cpu_base.hres_active remains setto 1 throughout. However, during a CPU unplug operation, the tick and theclockevents are shut down at CPUHP_AP_TICK_DYING. On return to the onlinestate, for instance CFS incorrectly assumes that the hrtick is alreadyactive, and the chance of the clockevent device to transition to oneshotmode is also lost forever for the CPU, unless it goes back to a lower statethan CPUHP_HRTIMERS_PREPARE once.This round-trip reveals another issue; cpu_base.online is not set to 1after the transition, which appears as a WARN_ON_ONCE in enqueue_hrtimer().Aside of that, the bulk of the per CPU state is not reset either, whichmeans there are dangling pointers in the worst case.Address this by adding a corresponding startup() callback, which resets thestale per CPU state and sets the online flag.[ tglx: Make the new callback unconditionally available, remove the online  &#x9;modification in the prepare() callback and clear the remaining  &#x9;state in the starting callback instead of the prepare callback ](CVE-2024-57951)In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_tcm: Don&#39;t free command immediatelyDon&#39;t prematurely free the command. Wait for the status completion ofthe sense status. It can be freed then. Otherwise we will double-freethe command.(CVE-2024-58055)In the Linux kernel, the following vulnerability has been resolved:net: davicom: fix UAF in dm9000_drv_removedm is netdev private data and it cannot beused after free_netdev() call. Using dm after free_netdev()can cause UAF bug. Fix it by moving free_netdev() at the end of thefunction.This is similar to the issue fixed in commitad297cd2db89 (&#34;net: qcom/emac: fix UAF in emac_remove&#34;).This bug is detected by our static analysis tool.(CVE-2025-21715)In the Linux kernel, the following vulnerability has been resolved:net: rose: fix timer races against user threadsRose timers only acquire the socket spinlock, withoutchecking if the socket is owned by one user thread.Add a check and rearm the timers if needed.BUG: KASAN: slab-use-after-free in rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174Read of size 2 at addr ffff88802f09b82a by task swapper/0/0CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5-syzkaller-00172-gd1bf27c4e176 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024Call Trace: &lt;IRQ&gt;  __dump_stack lib/dump_stack.c:94 [inline]  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120  print_address_description mm/kasan/report.c:378 [inline]  print_report+0x169/0x550 mm/kasan/report.c:489  kasan_report+0x143/0x180 mm/kasan/report.c:602  rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174  call_timer_fn+0x187/0x650 kernel/time/timer.c:1793  expire_timers kernel/time/timer.c:1844 [inline]  __run_timers kernel/time/timer.c:2418 [inline]  __run_timer_base+0x66a/0x8e0 kernel/time/timer.c:2430  run_timer_base kernel/time/timer.c:2439 [inline]  run_timer_softirq+0xb7/0x170 kernel/time/timer.c:2449  handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:561  __do_softirq kernel/softirq.c:595 [inline]  invoke_softirq kernel/softirq.c:435 [inline]  __irq_exit_rcu+0xf7/0x220 kernel/softirq.c:662  irq_exit_rcu+0x9/0x30 kernel/softirq.c:678  instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline]  sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1049 &lt;/IRQ&gt;(CVE-2025-21718)In the Linux kernel, the following vulnerability has been resolved:nilfs2: do not force clear folio if buffer is referencedPatch series &#34;nilfs2: protect busy buffer heads from being force-cleared&#34;.This series fixes the buffer head state inconsistency issues reported bysyzbot that occurs when the filesystem is corrupted and falls back toread-only, and the associated buffer head use-after-free issue.This patch (of 2):Syzbot has reported that after nilfs2 detects filesystem corruption andfalls back to read-only, inconsistencies in the buffer state may occur.One of the inconsistencies is that when nilfs2 calls mark_buffer_dirty()to set a data or metadata buffer as dirty, but it detects that the bufferis not in the uptodate state: WARNING: CPU: 0 PID: 6049 at fs/buffer.c:1177 mark_buffer_dirty+0x2e5/0x520  fs/buffer.c:1177 ... Call Trace:  &lt;TASK&gt;  nilfs_palloc_commit_alloc_entry+0x4b/0x160 fs/nilfs2/alloc.c:598  nilfs_ifile_create_inode+0x1dd/0x3a0 fs/nilfs2/ifile.c:73  nilfs_new_inode+0x254/0x830 fs/nilfs2/inode.c:344  nilfs_mkdir+0x10d/0x340 fs/nilfs2/namei.c:218  vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257  do_mkdirat+0x264/0x3a0 fs/namei.c:4280  __do_sys_mkdirat fs/namei.c:4295 [inline]  __se_sys_mkdirat fs/namei.c:4293 [inline]  __x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293  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/0x7fThe other is when nilfs_btree_propagate(), which propagates the dirtystate to the ancestor nodes of a b-tree that point to a dirty buffer,detects that the origin buffer is not dirty, even though it should be: WARNING: CPU: 0 PID: 5245 at fs/nilfs2/btree.c:2089  nilfs_btree_propagate+0xc79/0xdf0 fs/nilfs2/btree.c:2089 ... Call Trace:  &lt;TASK&gt;  nilfs_bmap_propagate+0x75/0x120 fs/nilfs2/bmap.c:345  nilfs_collect_file_data+0x4d/0xd0 fs/nilfs2/segment.c:587  nilfs_segctor_apply_buffers+0x184/0x340 fs/nilfs2/segment.c:1006  nilfs_segctor_scan_file+0x28c/0xa50 fs/nilfs2/segment.c:1045  nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1216 [inline]  nilfs_segctor_collect fs/nilfs2/segment.c:1540 [inline]  nilfs_segctor_do_construct+0x1c28/0x6b90 fs/nilfs2/segment.c:2115  nilfs_segctor_construct+0x181/0x6b0 fs/nilfs2/segment.c:2479  nilfs_segctor_thread_construct fs/nilfs2/segment.c:2587 [inline]  nilfs_segctor_thread+0x69e/0xe80 fs/nilfs2/segment.c:2701  kthread+0x2f0/0x390 kernel/kthread.c:389  ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244  &lt;/TASK&gt;Both of these issues are caused by the callbacks that handle thepage/folio write requests, forcibly clear various states, including theworking state of the buffers they hold, at unexpected times when theydetect read-only fallback.Fix these issues by checking if the buffer is referenced before clearingthe page/folio state, and skipping the clear if it is.(CVE-2025-21722)In the Linux kernel, the following vulnerability has been resolved:padata: avoid UAF for reorder_workAlthough the previous patch can avoid ps and ps UAF for _do_serial, itcan not avoid potential UAF issue for reorder_work. This issue canhappen just as below:crypto_request&#x9;&#x9;&#x9;crypto_request&#x9;&#x9;crypto_del_algpadata_do_serial  ...  padata_reorder    // processes all remaining    // requests then breaks    while (1) {      if (!padata)        break;      ...    }&#x9;&#x9;&#x9;&#x9;padata_do_serial&#x9;&#x9;&#x9;&#x9;  // new request added&#x9;&#x9;&#x9;&#x9;  list_add    // sees the new request    queue_work(reorder_work)&#x9;&#x9;&#x9;&#x9;  padata_reorder&#x9;&#x9;&#x9;&#x9;    queue_work_on(squeue-&gt;work)...&#x9;&#x9;&#x9;&#x9;&lt;kworker context&gt;&#x9;&#x9;&#x9;&#x9;padata_serial_worker&#x9;&#x9;&#x9;&#x9;// completes new request,&#x9;&#x9;&#x9;&#x9;// no more outstanding&#x9;&#x9;&#x9;&#x9;// requests&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;crypto_del_alg&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;  // free pd&lt;kworker context&gt;invoke_padata_reorder  // UAF of pdTo avoid UAF for &#39;reorder_work&#39;, get &#39;pd&#39; ref before put &#39;reorder_work&#39;into the &#39;serial_wq&#39; and put &#39;pd&#39; ref until the &#39;serial_wq&#39; finish.(CVE-2025-21726)In the Linux kernel, the following vulnerability has been resolved:padata: fix UAF in padata_reorderA bug was found when run ltp test:BUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0Read of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206CPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+Workqueue: pdecrypt_parallel padata_parallel_workerCall Trace:&lt;TASK&gt;dump_stack_lvl+0x32/0x50print_address_description.constprop.0+0x6b/0x3d0print_report+0xdd/0x2c0kasan_report+0xa5/0xd0padata_find_next+0x29/0x1a0padata_reorder+0x131/0x220padata_parallel_worker+0x3d/0xc0process_one_work+0x2ec/0x5a0If &#39;mdelay(10)&#39; is added before calling &#39;padata_find_next&#39; in the&#39;padata_reorder&#39; function, this issue could be reproduced easily withltp test (pcrypt_aead01).This can be explained as bellow:pcrypt_aead_encrypt...padata_do_parallelrefcount_inc(&amp;pd-&gt;refcnt); // add refcnt...padata_do_serialpadata_reorder // pdwhile (1) {padata_find_next(pd, true); // using pdqueue_work_on...padata_serial_worker&#x9;&#x9;&#x9;&#x9;crypto_del_algpadata_put_pd_cnt // sub refcnt&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;padata_free_shell&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;padata_put_pd(ps-&gt;pd);&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;// pd is freed// loop again, but pd is freed// call padata_find_next, UAF}In the padata_reorder function, when it loops in &#39;while&#39;, if the alg isdeleted, the refcnt may be decreased to 0 before entering&#39;padata_find_next&#39;, which leads to UAF.As mentioned in [1], do_serial is supposed to be called with BHs disabledand always happen under RCU protection, to address this issue, addsynchronize_rcu() in &#39;padata_free_shell&#39; wait for all _do_serial callsto finish.[1] https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.localdomain/[2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/(CVE-2025-21727)In the Linux kernel, the following vulnerability has been resolved:arm64: cacheinfo: Avoid out-of-bounds write to cacheinfo arrayThe loop that detects/populates cache information already has a boundscheck on the array size but does not account for cache levels withseparate data/instructions cache. Fix this by incrementing the indexfor any populated leaf (instead of any populated level).(CVE-2025-21785)In the Linux kernel, the following vulnerability has been resolved:vrf: use RCU protection in l3mdev_l3_out()l3mdev_l3_out() can be called without RCU being held:raw_sendmsg() ip_push_pending_frames()  ip_send_skb()   ip_local_out()    __ip_local_out()     l3mdev_ip_out()Add rcu_read_lock() / rcu_read_unlock() pair to avoida potential UAF.(CVE-2025-21791)In the Linux kernel, the following vulnerability has been resolved:PCI: rcar-ep: Fix incorrect variable used when calling devm_request_mem_region()The rcar_pcie_parse_outbound_ranges() uses the devm_request_mem_region()macro to request a needed resource. A string variable that lives on thestack is then used to store a dynamically computed resource name, whichis then passed on as one of the macro arguments. This can lead toundefined behavior.Depending on the current contents of the memory, the manifestations oferrors may vary. One possible output may be as follows:  $ cat /proc/iomem  30000000-37ffffff :  38000000-3fffffff :Sometimes, garbage may appear after the colon.In very rare cases, if no NULL-terminator is found in memory, the systemmight crash because the string iterator will overrun which can lead toaccess of unmapped memory above the stack.Thus, fix this by replacing outbound_name with the name of the previouslyrequested resource. With the changes applied, the output will be asfollows:  $ cat /proc/iomem  30000000-37ffffff : memory2  38000000-3fffffff : memory3[kwilczynski: commit log](CVE-2025-21804)In the Linux kernel, the following vulnerability has been resolved:hrtimers: Force migrate away hrtimers queued after CPUHP_AP_HRTIMERS_DYINGhrtimers are migrated away from the dying CPU to any online target atthe CPUHP_AP_HRTIMERS_DYING stage in order not to delay bandwidth timershandling tasks involved in the CPU hotplug forward progress.However wakeups can still be performed by the outgoing CPU afterCPUHP_AP_HRTIMERS_DYING. Those can result again in bandwidth timers beingarmed. Depending on several considerations (crystal ball power managementbased election, earliest timer already enqueued, timer migration enabled ornot), the target may eventually be the current CPU even if offline. If thathappens, the timer is eventually ignored.The most notable example is RCU which had to deal with each and every ofthose wake-ups by deferring them to an online CPU, along with relatedworkarounds:_ e787644caf76 (rcu: Defer RCU kthreads wakeup when CPU is dying)_ 9139f93209d1 (rcu/nocb: Fix RT throttling hrtimer armed from offline CPU)_ f7345ccc62a4 (rcu/nocb: Fix rcuog wake-up from offline softirq)The problem isn&#39;t confined to RCU though as the stop machine kthread(which runs CPUHP_AP_HRTIMERS_DYING) reports its completion at the endof its work through cpu_stop_signal_done() and performs a wake up thateventually arms the deadline server timer:   WARNING: CPU: 94 PID: 588 at kernel/time/hrtimer.c:1086 hrtimer_start_range_ns+0x289/0x2d0   CPU: 94 UID: 0 PID: 588 Comm: migration/94 Not tainted   Stopper: multi_cpu_stop+0x0/0x120 &lt;- stop_machine_cpuslocked+0x66/0xc0   RIP: 0010:hrtimer_start_range_ns+0x289/0x2d0   Call Trace:   &lt;TASK&gt;     start_dl_timer     enqueue_dl_entity     dl_server_start     enqueue_task_fair     enqueue_task     ttwu_do_activate     try_to_wake_up     complete     cpu_stopper_threadInstead of providing yet another bandaid to work around the situation, fixit in the hrtimers infrastructure instead: always migrate away a timer toan online target whenever it is enqueued from an offline CPU.This will also allow to revert all the above RCU disgraceful hacks.(CVE-2025-21816)In the Linux kernel, the following vulnerability has been resolved:batman-adv: Drop unmanaged ELP metric workerThe ELP worker needs to calculate new metric values for all neighbors&#34;reachable&#34; over an interface. Some of the used metric sources requirelocks which might need to sleep. This sleep is incompatible with the RCUlist iterator used for the recorded neighbors. The initial approach to workaround of this problem was to queue another work item per neighbor and thenrun this in a new context.Even when this solved the RCU vs might_sleep() conflict, it has a majorproblems: Nothing was stopping the work item in case it is not neededanymore - for example because one of the related interfaces was removed orthe batman-adv module was unloaded - resulting in potential invalid memoryaccesses.Directly canceling the metric worker also has various problems:* cancel_work_sync for a to-be-deactivated interface is called with  rtnl_lock held. But the code in the ELP metric worker also tries to use  rtnl_lock() - which will never return in this case. This also means that  cancel_work_sync would never return because it is waiting for the worker  to finish.* iterating over the neighbor list for the to-be-deactivated interface is  currently done using the RCU specific methods. Which means that it is  possible to miss items when iterating over it without the associated  spinlock - a behaviour which is acceptable for a periodic metric check  but not for a cleanup routine (which must &#34;stop&#34; all still running  workers)The better approch is to get rid of the per interface neighbor metricworker and handle everything in the interface worker. The original problemsare solved by:* creating a list of neighbors which require new metric information inside  the RCU protected context, gathering the metric according to the new list  outside the RCU protected context* only use rcu_trylock inside metric gathering code to avoid a deadlock  when the cancel_delayed_work_sync is called in the interface removal code  (which is called with the rtnl_lock held)(CVE-2025-21823)In the Linux kernel, the following vulnerability has been resolved:io_uring: prevent opcode speculationsqe-&gt;opcode is used for different tables, make sure we santitise itagainst speculations.(CVE-2025-21863)In the Linux kernel, the following vulnerability has been resolved:uprobes: Reject the shared zeropage in uprobe_write_opcode()We triggered the following crash in syzkaller tests:  BUG: Bad page state in process syz.7.38  pfn:1eff3  page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1eff3  flags: 0x3fffff00004004(referenced|reserved|node=0|zone=1|lastcpupid=0x1fffff)  raw: 003fffff00004004 ffffe6c6c07bfcc8 ffffe6c6c07bfcc8 0000000000000000  raw: 0000000000000000 0000000000000000 00000000fffffffe 0000000000000000  page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014  Call Trace:   &lt;TASK&gt;   dump_stack_lvl+0x32/0x50   bad_page+0x69/0xf0   free_unref_page_prepare+0x401/0x500   free_unref_page+0x6d/0x1b0   uprobe_write_opcode+0x460/0x8e0   install_breakpoint.part.0+0x51/0x80   register_for_each_vma+0x1d9/0x2b0   __uprobe_register+0x245/0x300   bpf_uprobe_multi_link_attach+0x29b/0x4f0   link_create+0x1e2/0x280   __sys_bpf+0x75f/0xac0   __x64_sys_bpf+0x1a/0x30   do_syscall_64+0x56/0x100   entry_SYSCALL_64_after_hwframe+0x78/0xe2   BUG: Bad rss-counter state mm:00000000452453e0 type:MM_FILEPAGES val:-1The following syzkaller test case can be used to reproduce:  r2 = creat(&amp;(0x7f0000000000)=&#39;./file0\x00&#39;, 0x8)  write$nbd(r2, &amp;(0x7f0000000580)=ANY=[], 0x10)  r4 = openat(0xffffffffffffff9c, &amp;(0x7f0000000040)=&#39;./file0\x00&#39;, 0x42, 0x0)  mmap$IORING_OFF_SQ_RING(&amp;(0x7f0000ffd000/0x3000)=nil, 0x3000, 0x0, 0x12, r4, 0x0)  r5 = userfaultfd(0x80801)  ioctl$UFFDIO_API(r5, 0xc018aa3f, &amp;(0x7f0000000040)={0xaa, 0x20})  r6 = userfaultfd(0x80801)  ioctl$UFFDIO_API(r6, 0xc018aa3f, &amp;(0x7f0000000140))  ioctl$UFFDIO_REGISTER(r6, 0xc020aa00, &amp;(0x7f0000000100)={{&amp;(0x7f0000ffc000/0x4000)=nil, 0x4000}, 0x2})  ioctl$UFFDIO_ZEROPAGE(r5, 0xc020aa04, &amp;(0x7f0000000000)={{&amp;(0x7f0000ffd000/0x1000)=nil, 0x1000}})  r7 = bpf$PROG_LOAD(0x5, &amp;(0x7f0000000140)={0x2, 0x3, &amp;(0x7f0000000200)=ANY=[@ANYBLOB=&#34;1800000000120000000000000000000095&#34;], &amp;(0x7f0000000000)=&#39;GPL\x00&#39;, 0x7, 0x0, 0x0, 0x0, 0x0, &#39;\x00&#39;, 0x0, @fallback=0x30, 0xffffffffffffffff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x10, 0x0, @void, @value}, 0x94)  bpf$BPF_LINK_CREATE_XDP(0x1c, &amp;(0x7f0000000040)={r7, 0x0, 0x30, 0x1e, @val=@uprobe_multi={&amp;(0x7f0000000080)=&#39;./file0\x00&#39;, &amp;(0x7f0000000100)=[0x2], 0x0, 0x0, 0x1}}, 0x40)The cause is that zero pfn is set to the PTE without increasing the RSScount in mfill_atomic_pte_zeropage() and the refcount of zero folio doesnot increase accordingly. Then, the operation on the same pfn is performedin uprobe_write_opcode()-&gt;__replace_page() to unconditional decrease theRSS count and old_folio&#39;s refcount.Therefore, two bugs are introduced: 1. The RSS count is incorrect, when process exit, the check_mm() report    error &#34;Bad rss-count&#34;. 2. The reserved folio (zero folio) is freed when folio-&gt;refcount is zero,    then free_pages_prepare-&gt;free_page_is_bad() report error    &#34;Bad page state&#34;.There is more, the following warning could also theoretically be triggered:  __replace_page()    -&gt; ...      -&gt; folio_remove_rmap_pte()        -&gt; VM_WARN_ON_FOLIO(is_zero_folio(folio), folio)Considering that uprobe hit on the zero folio is a very rare case, justreject zero old folio immediately after get_user_page_vma_remote().[ mingo: Cleaned up the changelog ](CVE-2025-21881)In the Linux kernel, the following vulnerability has been resolved:ovl: fix UAF in ovl_dentry_update_reval by moving dput() in ovl_link_upThe issue was caused by dput(upper) being called beforeovl_dentry_update_reval(), while upper-&gt;d_flags was stillaccessed in ovl_dentry_remote().Move dput(upper) after its last use to prevent use-after-free.BUG: KASAN: slab-use-after-free in ovl_dentry_remote fs/overlayfs/util.c:162 [inline]BUG: KASAN: slab-use-after-free in ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167Call Trace: &lt;TASK&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 ovl_dentry_remote fs/overlayfs/util.c:162 [inline] ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167 ovl_link_up fs/overlayfs/copy_up.c:610 [inline] ovl_copy_up_one+0x2105/0x3490 fs/overlayfs/copy_up.c:1170 ovl_copy_up_flags+0x18d/0x200 fs/overlayfs/copy_up.c:1223 ovl_rename+0x39e/0x18c0 fs/overlayfs/dir.c:1136 vfs_rename+0xf84/0x20a0 fs/namei.c:4893... &lt;/TASK&gt;(CVE-2025-21887)In the Linux kernel, the following vulnerability has been resolved:gpio: aggregator: protect driver attr handlers against module unloadBoth new_device_store and delete_device_store touch module globalresources (e.g. gpio_aggregator_lock). To prevent race conditions withmodule unload, a reference needs to be held.Add try_module_get() in these handlers.For new_device_store, this eliminates what appears to be the most dangerousscenario: if an id is allocated from gpio_aggregator_idr butplatform_device_register has not yet been called or completed, a concurrentmodule unload could fail to unregister/delete the device, leaving behind adangling platform device/GPIO forwarder. This can result in various issues.The following simple reproducer demonstrates these problems:  #!/bin/bash  while :; do    # note: whether &#39;gpiochip0 0&#39; exists or not does not matter.    echo &#39;gpiochip0 0&#39; &gt; /sys/bus/platform/drivers/gpio-aggregator/new_device  done &amp;  while :; do    modprobe gpio-aggregator    modprobe -r gpio-aggregator  done &amp;  wait  Starting with the following warning, several kinds of warnings will appear  and the system may become unstable:  ------------[ cut here ]------------  list_del corruption, ffff888103e2e980-&gt;next is LIST_POISON1 (dead000000000100)  WARNING: CPU: 1 PID: 1327 at lib/list_debug.c:56 __list_del_entry_valid_or_report+0xa3/0x120  [...]  RIP: 0010:__list_del_entry_valid_or_report+0xa3/0x120  [...]  Call Trace:   &lt;TASK&gt;   ? __list_del_entry_valid_or_report+0xa3/0x120   ? __warn.cold+0x93/0xf2   ? __list_del_entry_valid_or_report+0xa3/0x120   ? report_bug+0xe6/0x170   ? __irq_work_queue_local+0x39/0xe0   ? handle_bug+0x58/0x90   ? exc_invalid_op+0x13/0x60   ? asm_exc_invalid_op+0x16/0x20   ? __list_del_entry_valid_or_report+0xa3/0x120   gpiod_remove_lookup_table+0x22/0x60   new_device_store+0x315/0x350 [gpio_aggregator]   kernfs_fop_write_iter+0x137/0x1f0   vfs_write+0x262/0x430   ksys_write+0x60/0xd0   do_syscall_64+0x6c/0x180   entry_SYSCALL_64_after_hwframe+0x76/0x7e   [...]   &lt;/TASK&gt;  ---[ end trace 0000000000000000 ]---(CVE-2025-21943)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="bpftool" release="259.0.0.162.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="259.0.0.162.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="259.0.0.162.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="259.0.0.162.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="259.0.0.162.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="259.0.0.162.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="259.0.0.162.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="259.0.0.162.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="259.0.0.162.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="259.0.0.162.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="259.0.0.162.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="259.0.0.162.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="259.0.0.162.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="259.0.0.162.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="259.0.0.162.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-259.0.0.162.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="259.0.0.162.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="259.0.0.162.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="259.0.0.162.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="259.0.0.162.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="259.0.0.162.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="259.0.0.162.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="259.0.0.162.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="259.0.0.162.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="259.0.0.162.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="259.0.0.162.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="259.0.0.162.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="259.0.0.162.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="259.0.0.162.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="259.0.0.162.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="259.0.0.162.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-259.0.0.162.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1411</id>
          <title>An update for cobbler is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2025-04-11"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47533" id="CVE-2024-47533" title="CVE-2024-47533" type="cve"></reference>
          </references>
          <description>Cobbler, a Linux installation server that allows for rapid setup of network installation environments, has an improper authentication vulnerability starting in version 3.0.0 and prior to versions 3.2.3 and 3.3.7. `utils.get_shared_secret()` always returns `-1`, which allows anyone to connect to cobbler XML-RPC as user `&#39;&#39;` password `-1` and make any changes. This gives anyone with network access to a cobbler server full control of the server. Versions 3.2.3 and 3.3.7 fix the issue.(CVE-2024-47533)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="cobbler" release="4.oe2203sp4" version="3.2.0">
                         <filename>cobbler-3.2.0-4.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="cobbler-web" release="4.oe2203sp4" version="3.2.0">
                         <filename>cobbler-web-3.2.0-4.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1419</id>
          <title>An update for firefox is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-04-11"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-3028" id="CVE-2025-3028" title="CVE-2025-3028" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-3029" id="CVE-2025-3029" title="CVE-2025-3029" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-3030" id="CVE-2025-3030" title="CVE-2025-3030" type="cve"></reference>
          </references>
          <description>JavaScript code running while transforming a document with the XSLTProcessor could lead to a use-after-free. This vulnerability affects Firefox &lt; 137, Firefox ESR &lt; 115.22, Firefox ESR &lt; 128.9, Thunderbird &lt; 137, and Thunderbird &lt; 128.9.(CVE-2025-3028)A crafted URL containing specific Unicode characters could have hidden the true origin of the page, resulting in a potential spoofing attack. This vulnerability affects Firefox &lt; 137, Firefox ESR &lt; 128.9, Thunderbird &lt; 137, and Thunderbird &lt; 128.9.(CVE-2025-3029)Memory safety bugs present in Firefox 136, Thunderbird 136, Firefox ESR 128.8, and Thunderbird 128.8. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 137, Firefox ESR &lt; 128.9, Thunderbird &lt; 137, and Thunderbird &lt; 128.9.(CVE-2025-3030)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="firefox" release="1.oe2203sp4" version="128.9.0">
                         <filename>firefox-128.9.0-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="firefox-debuginfo" release="1.oe2203sp4" version="128.9.0">
                         <filename>firefox-debuginfo-128.9.0-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="firefox-debugsource" release="1.oe2203sp4" version="128.9.0">
                         <filename>firefox-debugsource-128.9.0-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox" release="1.oe2203sp4" version="128.9.0">
                         <filename>firefox-128.9.0-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox-debuginfo" release="1.oe2203sp4" version="128.9.0">
                         <filename>firefox-debuginfo-128.9.0-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox-debugsource" release="1.oe2203sp4" version="128.9.0">
                         <filename>firefox-debugsource-128.9.0-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1422</id>
          <title>An update for firefox is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-04-18"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45407" id="CVE-2022-45407" title="CVE-2022-45407" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45415" id="CVE-2022-45415" title="CVE-2022-45415" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-46873" id="CVE-2022-46873" title="CVE-2022-46873" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-46885" id="CVE-2022-46885" title="CVE-2022-46885" type="cve"></reference>
          </references>
          <description>If an attacker loaded a font using &lt;code&gt;FontFace()&lt;/code&gt; on a background worker, a use-after-free could have occurred, leading to a potentially exploitable crash. This vulnerability affects Firefox &lt; 107.(CVE-2022-45407)When downloading an HTML file, if the title of the page was formatted as a filename with a malicious extension, Firefox may have saved the file with that extension, leading to possible system compromise if the downloaded file was later ran. This vulnerability affects Firefox &lt; 107.(CVE-2022-45415)Because Firefox did not implement the &lt;code&gt;unsafe-hashes&lt;/code&gt; CSP directive, an attacker who was able to inject markup into a page otherwise protected by a Content Security Policy may have been able to inject executable script. This would be severely constrained by the specified Content Security Policy of the document. This vulnerability affects Firefox &lt; 108.(CVE-2022-46873)Mozilla developers Timothy Nikkel, Ashley Hale, and the Mozilla Fuzzing Team reported memory safety bugs present in Firefox 105. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 106.(CVE-2022-46885)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="firefox" release="1.oe2203sp4" version="128.9.0">
                         <filename>firefox-128.9.0-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="firefox-debuginfo" release="1.oe2203sp4" version="128.9.0">
                         <filename>firefox-debuginfo-128.9.0-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="firefox-debugsource" release="1.oe2203sp4" version="128.9.0">
                         <filename>firefox-debugsource-128.9.0-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox" release="1.oe2203sp4" version="128.9.0">
                         <filename>firefox-128.9.0-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox-debuginfo" release="1.oe2203sp4" version="128.9.0">
                         <filename>firefox-debuginfo-128.9.0-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox-debugsource" release="1.oe2203sp4" version="128.9.0">
                         <filename>firefox-debugsource-128.9.0-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1425</id>
          <title>An update for python-werkzeug is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-04-18"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49767" id="CVE-2024-49767" title="CVE-2024-49767" type="cve"></reference>
          </references>
          <description>Werkzeug is a Web Server Gateway Interface web application library. Applications using `werkzeug.formparser.MultiPartParser` corresponding to a version of Werkzeug prior to 3.0.6 to parse `multipart/form-data` requests (e.g. all flask applications) are vulnerable to a relatively simple but effective resource exhaustion (denial of service) attack. A specifically crafted form submission request can cause the parser to allocate and block 3 to 8 times the upload size in main memory. There is no upper limit; a single upload at 1 Gbit/s can exhaust 32 GB of RAM in less than 60 seconds. Werkzeug version 3.0.6 fixes this issue.(CVE-2024-49767)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="python-werkzeug-help" release="5.oe2203sp4" version="2.0.3">
                         <filename>python-werkzeug-help-2.0.3-5.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-werkzeug" release="5.oe2203sp4" version="2.0.3">
                         <filename>python3-werkzeug-2.0.3-5.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1427</id>
          <title>An update for golang is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-04-18"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-22870" id="CVE-2025-22870" title="CVE-2025-22870" type="cve"></reference>
          </references>
          <description>Matching of hosts against proxy patterns can improperly treat an IPv6 zone ID as a hostname component. For example, when the NO_PROXY environment variable is set to &#34;*.example.com&#34;, a request to &#34;[::1%25.example.com]:80` will incorrectly match and not be proxied.(CVE-2025-22870)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="golang" release="39.oe2203sp4" version="1.17.3">
                         <filename>golang-1.17.3-39.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="golang-devel" release="39.oe2203sp4" version="1.17.3">
                         <filename>golang-devel-1.17.3-39.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="golang-help" release="39.oe2203sp4" version="1.17.3">
                         <filename>golang-help-1.17.3-39.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="golang" release="39.oe2203sp4" version="1.17.3">
                         <filename>golang-1.17.3-39.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1428</id>
          <title>An update for augeas is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2025-04-18"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-2588" id="CVE-2025-2588" title="CVE-2025-2588" type="cve"></reference>
          </references>
          <description>A vulnerability has been found in Hercules Augeas 1.14.1 and classified as problematic. This vulnerability affects the function re_case_expand of the file src/fa.c. The manipulation of the argument re leads to null pointer dereference. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used.(CVE-2025-2588)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="augeas" release="6.oe2203sp4" version="1.13.0">
                         <filename>augeas-1.13.0-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="augeas-debuginfo" release="6.oe2203sp4" version="1.13.0">
                         <filename>augeas-debuginfo-1.13.0-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="augeas-debugsource" release="6.oe2203sp4" version="1.13.0">
                         <filename>augeas-debugsource-1.13.0-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="augeas-devel" release="6.oe2203sp4" version="1.13.0">
                         <filename>augeas-devel-1.13.0-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="augeas-help" release="6.oe2203sp4" version="1.13.0">
                         <filename>augeas-help-1.13.0-6.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="augeas" release="6.oe2203sp4" version="1.13.0">
                         <filename>augeas-1.13.0-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="augeas-debuginfo" release="6.oe2203sp4" version="1.13.0">
                         <filename>augeas-debuginfo-1.13.0-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="augeas-debugsource" release="6.oe2203sp4" version="1.13.0">
                         <filename>augeas-debugsource-1.13.0-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="augeas-devel" release="6.oe2203sp4" version="1.13.0">
                         <filename>augeas-devel-1.13.0-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1429</id>
          <title>An update for xorg-x11-server is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-04-18"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-26594" id="CVE-2025-26594" title="CVE-2025-26594" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-26595" id="CVE-2025-26595" title="CVE-2025-26595" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-26596" id="CVE-2025-26596" title="CVE-2025-26596" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-26597" id="CVE-2025-26597" title="CVE-2025-26597" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-26598" id="CVE-2025-26598" title="CVE-2025-26598" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-26599" id="CVE-2025-26599" title="CVE-2025-26599" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-26600" id="CVE-2025-26600" title="CVE-2025-26600" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-26601" id="CVE-2025-26601" title="CVE-2025-26601" type="cve"></reference>
          </references>
          <description>A use-after-free flaw was found in X.Org and Xwayland. The root cursor is referenced in the X server as a global variable. If a client frees the root cursor, the internal reference points to freed memory and causes a use-after-free.(CVE-2025-26594)A buffer overflow flaw was found in X.Org and Xwayland. The code in XkbVModMaskText() allocates a fixed-sized buffer on the stack and copies the names of the virtual modifiers to that buffer. The code fails to check the bounds of the buffer and would copy the data regardless of the size.(CVE-2025-26595)A heap overflow flaw was found in X.Org and Xwayland. The computation of the length in XkbSizeKeySyms() differs from what is written in XkbWriteKeySyms(), which may lead to a heap-based buffer overflow.(CVE-2025-26596)A buffer overflow flaw was found in X.Org and Xwayland. If XkbChangeTypesOfKey() is called with a 0 group, it will resize the key symbols table to 0 but leave the key actions unchanged. If the same function is later called with a non-zero value of groups, this will cause a buffer overflow because the key actions are of the wrong size.(CVE-2025-26597)An out-of-bounds write flaw was found in X.Org and Xwayland. The function GetBarrierDevice() searches for the pointer device based on its device ID and returns the matching value, or supposedly NULL, if no match was found. However, the code will return the last element of the list if no matching device ID is found, which can lead to out-of-bounds memory access.(CVE-2025-26598)An access to an uninitialized pointer flaw was found in X.Org and Xwayland. The function compCheckRedirect() may fail if it cannot allocate the backing pixmap. In that case, compRedirectWindow() will return a BadAlloc error without validating the window tree marked just before, which leaves the validated data partly initialized and the use of an uninitialized pointer later.(CVE-2025-26599)A use-after-free flaw was found in X.Org and Xwayland. When a device is removed while still frozen, the events queued for that device remain while the device is freed. Replaying the events will cause a use-after-free.(CVE-2025-26600)A use-after-free flaw was found in X.Org and Xwayland. When changing an alarm, the values of the change mask are evaluated one after the other, changing the trigger values as requested, and eventually, SyncInitTrigger() is called. If one of the changes triggers an error, the function will return early, not adding the new sync object, possibly causing a use-after-free when the alarm eventually triggers.(CVE-2025-26601)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="xorg-x11-server" release="35.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-1.20.11-35.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-Xdmx" release="35.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-Xdmx-1.20.11-35.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-Xephyr" release="35.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-Xephyr-1.20.11-35.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-Xnest" release="35.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-Xnest-1.20.11-35.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-Xvfb" release="35.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-Xvfb-1.20.11-35.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-common" release="35.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-common-1.20.11-35.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-debuginfo" release="35.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-debuginfo-1.20.11-35.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-debugsource" release="35.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-debugsource-1.20.11-35.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-devel" release="35.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-devel-1.20.11-35.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="xorg-x11-server-help" release="35.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-help-1.20.11-35.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="xorg-x11-server-source" release="35.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-source-1.20.11-35.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server" release="35.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-1.20.11-35.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xdmx" release="35.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-Xdmx-1.20.11-35.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xephyr" release="35.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-Xephyr-1.20.11-35.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xnest" release="35.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-Xnest-1.20.11-35.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xvfb" release="35.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-Xvfb-1.20.11-35.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-common" release="35.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-common-1.20.11-35.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-debuginfo" release="35.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-debuginfo-1.20.11-35.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-debugsource" release="35.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-debugsource-1.20.11-35.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-devel" release="35.oe2203sp4" version="1.20.11">
                         <filename>xorg-x11-server-devel-1.20.11-35.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1434</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-04-18"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49246" id="CVE-2022-49246" title="CVE-2022-49246" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49328" id="CVE-2022-49328" title="CVE-2022-49328" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57980" id="CVE-2024-57980" title="CVE-2024-57980" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21858" id="CVE-2025-21858" title="CVE-2025-21858" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21928" id="CVE-2025-21928" title="CVE-2025-21928" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:ASoC: atmel: Fix error handling in snd_proto_probeThe device_node pointer is returned by of_parse_phandle()  with refcountincremented. We should use of_node_put() on it when done.This function only calls of_node_put() in the regular path.And it will cause refcount leak in error paths.Fix this by calling of_node_put() in error handling too.(CVE-2022-49246)In the Linux kernel, the following vulnerability has been resolved:mt76: fix use-after-free by removing a non-RCU wcid pointerFixes an issue caught by KASAN about use-after-free in mt76_txq_scheduleby protecting mtxq-&gt;wcid with rcu_lock between mt76_txq_schedule andsta_info_[alloc, free].[18853.876689] ==================================================================[18853.876751] BUG: KASAN: use-after-free in mt76_txq_schedule+0x204/0xaf8 [mt76][18853.876773] Read of size 8 at addr ffffffaf989a2138 by task mt76-tx phy0/883[18853.876786][18853.876810] CPU: 5 PID: 883 Comm: mt76-tx phy0 Not tainted 5.10.100-fix-510-56778d365941-kasan #5 0b01fbbcf41a530f52043508fec2e31a4215[18853.876840] Call trace:[18853.876861]  dump_backtrace+0x0/0x3ec[18853.876878]  show_stack+0x20/0x2c[18853.876899]  dump_stack+0x11c/0x1ac[18853.876918]  print_address_description+0x74/0x514[18853.876934]  kasan_report+0x134/0x174[18853.876948]  __asan_report_load8_noabort+0x44/0x50[18853.876976]  mt76_txq_schedule+0x204/0xaf8 [mt76 074e03e4640e97fe7405ee1fab547b81c4fa45d2][18853.877002]  mt76_txq_schedule_all+0x2c/0x48 [mt76 074e03e4640e97fe7405ee1fab547b81c4fa45d2][18853.877030]  mt7921_tx_worker+0xa0/0x1cc [mt7921_common f0875ebac9d7b4754e1010549e7db50fbd90a047][18853.877054]  __mt76_worker_fn+0x190/0x22c [mt76 074e03e4640e97fe7405ee1fab547b81c4fa45d2][18853.877071]  kthread+0x2f8/0x3b8[18853.877087]  ret_from_fork+0x10/0x30[18853.877098][18853.877112] Allocated by task 941:[18853.877131]  kasan_save_stack+0x38/0x68[18853.877147]  __kasan_kmalloc+0xd4/0xfc[18853.877163]  kasan_kmalloc+0x10/0x1c[18853.877177]  __kmalloc+0x264/0x3c4[18853.877294]  sta_info_alloc+0x460/0xf88 [mac80211][18853.877410]  ieee80211_prep_connection+0x204/0x1ee0 [mac80211][18853.877523]  ieee80211_mgd_auth+0x6c4/0xa4c [mac80211][18853.877635]  ieee80211_auth+0x20/0x2c [mac80211][18853.877733]  rdev_auth+0x7c/0x438 [cfg80211][18853.877826]  cfg80211_mlme_auth+0x26c/0x390 [cfg80211][18853.877919]  nl80211_authenticate+0x6d4/0x904 [cfg80211][18853.877938]  genl_rcv_msg+0x748/0x93c[18853.877954]  netlink_rcv_skb+0x160/0x2a8[18853.877969]  genl_rcv+0x3c/0x54[18853.877985]  netlink_unicast_kernel+0x104/0x1ec[18853.877999]  netlink_unicast+0x178/0x268[18853.878015]  netlink_sendmsg+0x3cc/0x5f0[18853.878030]  sock_sendmsg+0xb4/0xd8[18853.878043]  ____sys_sendmsg+0x2f8/0x53c[18853.878058]  ___sys_sendmsg+0xe8/0x150[18853.878071]  __sys_sendmsg+0xc4/0x1f4[18853.878087]  __arm64_compat_sys_sendmsg+0x88/0x9c[18853.878101]  el0_svc_common+0x1b4/0x390[18853.878115]  do_el0_svc_compat+0x8c/0xdc[18853.878131]  el0_svc_compat+0x10/0x1c[18853.878146]  el0_sync_compat_handler+0xa8/0xcc[18853.878161]  el0_sync_compat+0x188/0x1c0[18853.878171][18853.878183] Freed by task 10927:[18853.878200]  kasan_save_stack+0x38/0x68[18853.878215]  kasan_set_track+0x28/0x3c[18853.878228]  kasan_set_free_info+0x24/0x48[18853.878244]  __kasan_slab_free+0x11c/0x154[18853.878259]  kasan_slab_free+0x14/0x24[18853.878273]  slab_free_freelist_hook+0xac/0x1b0[18853.878287]  kfree+0x104/0x390[18853.878402]  sta_info_free+0x198/0x210 [mac80211][18853.878515]  __sta_info_destroy_part2+0x230/0x2d4 [mac80211][18853.878628]  __sta_info_flush+0x300/0x37c [mac80211][18853.878740]  ieee80211_set_disassoc+0x2cc/0xa7c [mac80211][18853.878851]  ieee80211_mgd_deauth+0x4a4/0x10a0 [mac80211][18853.878962]  ieee80211_deauth+0x20/0x2c [mac80211][18853.879057]  rdev_deauth+0x7c/0x438 [cfg80211][18853.879150]  cfg80211_mlme_deauth+0x274/0x414 [cfg80211][18853.879243]  cfg80211_mlme_down+0xe4/0x118 [cfg80211][18853.879335]  cfg80211_disconnect+0x218/0x2d8 [cfg80211][18853.879427]  __cfg80211_leave+0x17c/0x240 [cfg80211][18853.879519]  cfg80211_leave+0x3c/0x58 [cfg80211][18853.879611]  wiphy_suspend+0xdc/0x200 [cfg80211][18853.879628]  dpm_run_callback+0x58/0x408[18853.879642]  __device_suspend+0x4cc/0x864[18853.879658]  async_suspend+0x34/0xf4[18---truncated---(CVE-2022-49328)In the Linux kernel, the following vulnerability has been resolved:media: uvcvideo: Fix double free in error pathIf the uvc_status_init() function fails to allocate the int_urb, it willfree the dev-&gt;status pointer but doesn&#39;t reset the pointer to NULL. Thisresults in the kfree() call in uvc_status_cleanup() trying todouble-free the memory. Fix it by resetting the dev-&gt;status pointer toNULL after freeing it.Reviewed by: Ricardo Ribalda &lt;ribalda@chromium.org&gt;(CVE-2024-57980)In the Linux kernel, the following vulnerability has been resolved:geneve: Fix use-after-free in geneve_find_dev().syzkaller reported a use-after-free in geneve_find_dev() [0]without repro.geneve_configure() links struct geneve_dev.next tonet_generic(net, geneve_net_id)-&gt;geneve_list.The net here could differ from dev_net(dev) if IFLA_NET_NS_PID,IFLA_NET_NS_FD, or IFLA_TARGET_NETNSID is set.When dev_net(dev) is dismantled, geneve_exit_batch_rtnl() finallycalls unregister_netdevice_queue() for each dev in the netns,and later the dev is freed.However, its geneve_dev.next is still linked to the backend UDPsocket netns.Then, use-after-free will occur when another geneve dev is createdin the netns.Let&#39;s call geneve_dellink() instead in geneve_destroy_tunnels().[0]:BUG: KASAN: slab-use-after-free in geneve_find_dev drivers/net/geneve.c:1295 [inline]BUG: KASAN: slab-use-after-free in geneve_configure+0x234/0x858 drivers/net/geneve.c:1343Read of size 2 at addr ffff000054d6ee24 by task syz.1.4029/13441CPU: 1 UID: 0 PID: 13441 Comm: syz.1.4029 Not tainted 6.13.0-g0ad9617c78ac #24 dc35ca22c79fb82e8e7bc5c9c9adafea898b1e3dHardware name: linux,dummy-virt (DT)Call trace: show_stack+0x38/0x50 arch/arm64/kernel/stacktrace.c:466 (C) __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xbc/0x108 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x16c/0x6f0 mm/kasan/report.c:489 kasan_report+0xc0/0x120 mm/kasan/report.c:602 __asan_report_load2_noabort+0x20/0x30 mm/kasan/report_generic.c:379 geneve_find_dev drivers/net/geneve.c:1295 [inline] geneve_configure+0x234/0x858 drivers/net/geneve.c:1343 geneve_newlink+0xb8/0x128 drivers/net/geneve.c:1634 rtnl_newlink_create+0x23c/0x868 net/core/rtnetlink.c:3795 __rtnl_newlink net/core/rtnetlink.c:3906 [inline] rtnl_newlink+0x1054/0x1630 net/core/rtnetlink.c:4021 rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6911 netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2543 rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6938 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0x618/0x838 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x5fc/0x8b0 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:713 [inline] __sock_sendmsg net/socket.c:728 [inline] ____sys_sendmsg+0x410/0x6f8 net/socket.c:2568 ___sys_sendmsg+0x178/0x1d8 net/socket.c:2622 __sys_sendmsg net/socket.c:2654 [inline] __do_sys_sendmsg net/socket.c:2659 [inline] __se_sys_sendmsg net/socket.c:2657 [inline] __arm64_sys_sendmsg+0x12c/0x1c8 net/socket.c:2657 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x90/0x278 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x13c/0x250 arch/arm64/kernel/syscall.c:132 do_el0_svc+0x54/0x70 arch/arm64/kernel/syscall.c:151 el0_svc+0x4c/0xa8 arch/arm64/kernel/entry-common.c:744 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:762 el0t_64_sync+0x198/0x1a0 arch/arm64/kernel/entry.S:600Allocated by task 13247: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x30/0x68 mm/kasan/common.c:68 kasan_save_alloc_info+0x44/0x58 mm/kasan/generic.c:568 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x84/0xa0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4298 [inline] __kmalloc_node_noprof+0x2a0/0x560 mm/slub.c:4304 __kvmalloc_node_noprof+0x9c/0x230 mm/util.c:645 alloc_netdev_mqs+0xb8/0x11a0 net/core/dev.c:11470 rtnl_create_link+0x2b8/0xb50 net/core/rtnetlink.c:3604 rtnl_newlink_create+0x19c/0x868 net/core/rtnetlink.c:3780 __rtnl_newlink net/core/rtnetlink.c:3906 [inline] rtnl_newlink+0x1054/0x1630 net/core/rtnetlink.c:4021 rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6911 netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2543 rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6938 netlink_unicast_kernel net/netlink/af_n---truncated---(CVE-2025-21858)In the Linux kernel, the following vulnerability has been resolved:HID: intel-ish-hid: Fix use-after-free issue in ishtp_hid_remove()The system can experience a random crash a few minutes after the driver isremoved. This issue occurs due to improper handling of memory freeing inthe ishtp_hid_remove() function.The function currently frees the `driver_data` directly within the loopthat destroys the HID devices, which can lead to accessing freed memory.Specifically, `hid_destroy_device()` uses `driver_data` when it calls`hid_ishtp_set_feature()` to power off the sensor, so freeing`driver_data` beforehand can result in accessing invalid memory.This patch resolves the issue by storing the `driver_data` in a temporaryvariable before calling `hid_destroy_device()`, and then freeing the`driver_data` after the device is destroyed.(CVE-2025-21928)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="bpftool" release="260.0.0.163.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-260.0.0.163.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="260.0.0.163.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-260.0.0.163.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="260.0.0.163.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-260.0.0.163.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="260.0.0.163.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-260.0.0.163.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="260.0.0.163.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-260.0.0.163.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="260.0.0.163.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-260.0.0.163.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="260.0.0.163.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-260.0.0.163.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="260.0.0.163.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-260.0.0.163.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="260.0.0.163.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-260.0.0.163.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="260.0.0.163.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-260.0.0.163.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="260.0.0.163.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-260.0.0.163.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="260.0.0.163.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-260.0.0.163.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="260.0.0.163.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-260.0.0.163.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="260.0.0.163.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-260.0.0.163.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="260.0.0.163.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-260.0.0.163.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="260.0.0.163.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-260.0.0.163.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="260.0.0.163.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-260.0.0.163.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="260.0.0.163.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-260.0.0.163.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="260.0.0.163.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-260.0.0.163.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="260.0.0.163.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-260.0.0.163.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="260.0.0.163.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-260.0.0.163.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="260.0.0.163.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-260.0.0.163.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="260.0.0.163.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-260.0.0.163.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="260.0.0.163.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-260.0.0.163.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="260.0.0.163.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-260.0.0.163.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="260.0.0.163.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-260.0.0.163.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="260.0.0.163.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-260.0.0.163.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="260.0.0.163.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-260.0.0.163.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="260.0.0.163.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-260.0.0.163.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="260.0.0.163.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-260.0.0.163.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1437</id>
          <title>An update for mariadb is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-04-18"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21490" id="CVE-2025-21490" title="CVE-2025-21490" type="cve"></reference>
          </references>
          <description>Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.40 and prior, 8.4.3 and prior and  9.1.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).(CVE-2025-21490)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="mariadb" release="1.oe2203sp4" version="10.5.28">
                         <filename>mariadb-10.5.28-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-backup" release="1.oe2203sp4" version="10.5.28">
                         <filename>mariadb-backup-10.5.28-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-common" release="1.oe2203sp4" version="10.5.28">
                         <filename>mariadb-common-10.5.28-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-config" release="1.oe2203sp4" version="10.5.28">
                         <filename>mariadb-config-10.5.28-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-debuginfo" release="1.oe2203sp4" version="10.5.28">
                         <filename>mariadb-debuginfo-10.5.28-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-debugsource" release="1.oe2203sp4" version="10.5.28">
                         <filename>mariadb-debugsource-10.5.28-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-devel" release="1.oe2203sp4" version="10.5.28">
                         <filename>mariadb-devel-10.5.28-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-embedded" release="1.oe2203sp4" version="10.5.28">
                         <filename>mariadb-embedded-10.5.28-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-embedded-devel" release="1.oe2203sp4" version="10.5.28">
                         <filename>mariadb-embedded-devel-10.5.28-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-errmsg" release="1.oe2203sp4" version="10.5.28">
                         <filename>mariadb-errmsg-10.5.28-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-gssapi-server" release="1.oe2203sp4" version="10.5.28">
                         <filename>mariadb-gssapi-server-10.5.28-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-oqgraph-engine" release="1.oe2203sp4" version="10.5.28">
                         <filename>mariadb-oqgraph-engine-10.5.28-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-pam" release="1.oe2203sp4" version="10.5.28">
                         <filename>mariadb-pam-10.5.28-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-rocksdb-engine" release="1.oe2203sp4" version="10.5.28">
                         <filename>mariadb-rocksdb-engine-10.5.28-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-server" release="1.oe2203sp4" version="10.5.28">
                         <filename>mariadb-server-10.5.28-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-server-galera" release="1.oe2203sp4" version="10.5.28">
                         <filename>mariadb-server-galera-10.5.28-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-server-utils" release="1.oe2203sp4" version="10.5.28">
                         <filename>mariadb-server-utils-10.5.28-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-test" release="1.oe2203sp4" version="10.5.28">
                         <filename>mariadb-test-10.5.28-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb" release="1.oe2203sp4" version="10.5.28">
                         <filename>mariadb-10.5.28-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-backup" release="1.oe2203sp4" version="10.5.28">
                         <filename>mariadb-backup-10.5.28-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-common" release="1.oe2203sp4" version="10.5.28">
                         <filename>mariadb-common-10.5.28-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-config" release="1.oe2203sp4" version="10.5.28">
                         <filename>mariadb-config-10.5.28-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-debuginfo" release="1.oe2203sp4" version="10.5.28">
                         <filename>mariadb-debuginfo-10.5.28-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-debugsource" release="1.oe2203sp4" version="10.5.28">
                         <filename>mariadb-debugsource-10.5.28-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-devel" release="1.oe2203sp4" version="10.5.28">
                         <filename>mariadb-devel-10.5.28-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-embedded" release="1.oe2203sp4" version="10.5.28">
                         <filename>mariadb-embedded-10.5.28-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-embedded-devel" release="1.oe2203sp4" version="10.5.28">
                         <filename>mariadb-embedded-devel-10.5.28-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-errmsg" release="1.oe2203sp4" version="10.5.28">
                         <filename>mariadb-errmsg-10.5.28-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-gssapi-server" release="1.oe2203sp4" version="10.5.28">
                         <filename>mariadb-gssapi-server-10.5.28-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-oqgraph-engine" release="1.oe2203sp4" version="10.5.28">
                         <filename>mariadb-oqgraph-engine-10.5.28-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-pam" release="1.oe2203sp4" version="10.5.28">
                         <filename>mariadb-pam-10.5.28-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-server" release="1.oe2203sp4" version="10.5.28">
                         <filename>mariadb-server-10.5.28-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-server-galera" release="1.oe2203sp4" version="10.5.28">
                         <filename>mariadb-server-galera-10.5.28-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-server-utils" release="1.oe2203sp4" version="10.5.28">
                         <filename>mariadb-server-utils-10.5.28-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-test" release="1.oe2203sp4" version="10.5.28">
                         <filename>mariadb-test-10.5.28-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1441</id>
          <title>An update for libsoup is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-04-18"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-2784" id="CVE-2025-2784" title="CVE-2025-2784" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-32050" id="CVE-2025-32050" title="CVE-2025-32050" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-32052" id="CVE-2025-32052" title="CVE-2025-32052" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-32053" id="CVE-2025-32053" title="CVE-2025-32053" type="cve"></reference>
          </references>
          <description>A flaw was found in libsoup. The package is vulnerable to a heap buffer over-read when sniffing content via the skip_insight_whitespace() function. Libsoup clients may read one byte out-of-bounds in response to a crafted HTTP response by an HTTP server.(CVE-2025-2784)A flaw was found in libsoup. The libsoup append_param_quoted() function may contain an overflow bug resulting in a buffer under-read.(CVE-2025-32050)A flaw was found in libsoup. A vulnerability in the sniff_unknown() function may lead to heap buffer over-read.(CVE-2025-32052)A flaw was found in libsoup. A vulnerability in sniff_feed_or_html() and skip_insignificant_space() functions may lead to a heap buffer over-read.(CVE-2025-32053)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libsoup" release="6.oe2203sp4" version="2.74.2">
                         <filename>libsoup-2.74.2-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libsoup-debuginfo" release="6.oe2203sp4" version="2.74.2">
                         <filename>libsoup-debuginfo-2.74.2-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libsoup-debugsource" release="6.oe2203sp4" version="2.74.2">
                         <filename>libsoup-debugsource-2.74.2-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libsoup-devel" release="6.oe2203sp4" version="2.74.2">
                         <filename>libsoup-devel-2.74.2-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="libsoup-help" release="6.oe2203sp4" version="2.74.2">
                         <filename>libsoup-help-2.74.2-6.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libsoup" release="6.oe2203sp4" version="2.74.2">
                         <filename>libsoup-2.74.2-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libsoup-debuginfo" release="6.oe2203sp4" version="2.74.2">
                         <filename>libsoup-debuginfo-2.74.2-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libsoup-debugsource" release="6.oe2203sp4" version="2.74.2">
                         <filename>libsoup-debugsource-2.74.2-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libsoup-devel" release="6.oe2203sp4" version="2.74.2">
                         <filename>libsoup-devel-2.74.2-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1443</id>
          <title>An update for mod_auth_openidc is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-04-18"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-31492" id="CVE-2025-31492" title="CVE-2025-31492" 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. Prior to 2.4.16.11, a bug in a mod_auth_openidc results in disclosure of protected content to unauthenticated users. The conditions for disclosure are an OIDCProviderAuthRequestMethod POST, a valid account, and there mustn&#39;t be any application-level gateway (or load balancer etc) protecting the server. When you request a protected resource, the response includes the HTTP status, the HTTP headers, the intended response (the self-submitting form), and the protected resource (with no headers). This is an example of a request for a protected resource, including all the data returned. In the case where mod_auth_openidc returns a form, it has to return OK from check_userid so as not to go down the error path in httpd. This means httpd will try to issue the protected resource. oidc_content_handler is called early, which has the opportunity to prevent the normal output being issued by httpd. oidc_content_handler has a number of checks for when it intervenes, but it doesn&#39;t check for this case, so the handler returns DECLINED. Consequently, httpd appends the protected content to the response. The issue has been patched in mod_auth_openidc versions &gt;= 2.4.16.11.(CVE-2025-31492)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="mod_auth_openidc" release="1.oe2203sp4" version="2.4.16.11">
                         <filename>mod_auth_openidc-2.4.16.11-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_auth_openidc-debuginfo" release="1.oe2203sp4" version="2.4.16.11">
                         <filename>mod_auth_openidc-debuginfo-2.4.16.11-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_auth_openidc-debugsource" release="1.oe2203sp4" version="2.4.16.11">
                         <filename>mod_auth_openidc-debugsource-2.4.16.11-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_auth_openidc" release="1.oe2203sp4" version="2.4.16.11">
                         <filename>mod_auth_openidc-2.4.16.11-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_auth_openidc-debuginfo" release="1.oe2203sp4" version="2.4.16.11">
                         <filename>mod_auth_openidc-debuginfo-2.4.16.11-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_auth_openidc-debugsource" release="1.oe2203sp4" version="2.4.16.11">
                         <filename>mod_auth_openidc-debugsource-2.4.16.11-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1449</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-04-25"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52935" id="CVE-2023-52935" title="CVE-2023-52935" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53010" id="CVE-2023-53010" title="CVE-2023-53010" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21780" id="CVE-2025-21780" title="CVE-2025-21780" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21781" id="CVE-2025-21781" title="CVE-2025-21781" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21877" id="CVE-2025-21877" title="CVE-2025-21877" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21898" id="CVE-2025-21898" title="CVE-2025-21898" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21935" id="CVE-2025-21935" title="CVE-2025-21935" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21993" id="CVE-2025-21993" title="CVE-2025-21993" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-22035" id="CVE-2025-22035" title="CVE-2025-22035" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:mm/khugepaged: fix -&gt;anon_vma raceIf an -&gt;anon_vma is attached to the VMA, collapse_and_free_pmd() requiresit to be locked.Page table traversal is allowed under any one of the mmap lock, theanon_vma lock (if the VMA is associated with an anon_vma), and themapping lock (if the VMA is associated with a mapping); and so to beable to remove page tables, we must hold all three of them. retract_page_tables() bails out if an -&gt;anon_vma is attached, but doesthis check before holding the mmap lock (as the comment above the checkexplains).If we racily merged an existing -&gt;anon_vma (shared with a childprocess) from a neighboring VMA, subsequent rmap traversals on pagesbelonging to the child will be able to see the page tables that we areconcurrently removing while assuming that nothing else can access them.Repeat the -&gt;anon_vma check once we hold the mmap lock to ensure thatthere really is no concurrent page table access.Hitting this bug causes a lockdep warning in collapse_and_free_pmd(),in the line &#34;lockdep_assert_held_write(&amp;vma-&gt;anon_vma-&gt;root-&gt;rwsem)&#34;. It can also lead to use-after-free access.(CVE-2023-52935)In the Linux kernel, the following vulnerability has been resolved:bnxt: Do not read past the end of test namesTest names were being concatenated based on a offset beyond the end ofthe first name, which tripped the buffer overflow detection logic: detected buffer overflow in strnlen [...] Call Trace: bnxt_ethtool_init.cold+0x18/0x18Refactor struct hwrm_selftest_qlist_output to use an actual array,and adjust the concatenation to use snprintf() rather than a series ofstrncat() calls.(CVE-2023-53010)In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: avoid buffer overflow attach in smu_sys_set_pp_table()It malicious user provides a small pptable through sysfs and thena bigger pptable, it may cause buffer overflow attack in functionsmu_sys_set_pp_table().(CVE-2025-21780)In the Linux kernel, the following vulnerability has been resolved:batman-adv: fix panic during interface removalReference counting is used to ensure thatbatadv_hardif_neigh_node and batadv_hard_ifaceare not freed before/duringbatadv_v_elp_throughput_metric_update work isfinished.But there isn&#39;t a guarantee that the hard if willremain associated with a soft interface up untilthe work is finished.This fixes a crash triggered by reboot that lookslike this:Call trace: batadv_v_mesh_free+0xd0/0x4dc [batman_adv] batadv_v_elp_throughput_metric_update+0x1c/0xa4 process_one_work+0x178/0x398 worker_thread+0x2e8/0x4d0 kthread+0xd8/0xdc ret_from_fork+0x10/0x20(the batadv_v_mesh_free call is misleading,and does not actually happen)I was able to make the issue happen more reliablyby changing hardif_neigh-&gt;bat_v.metric_work workto be delayed work. This allowed me to track downand confirm the fix.[sven@narfation.org: prevent entering batadv_v_elp_get_throughput without soft_iface](CVE-2025-21781)In the Linux kernel, the following vulnerability has been resolved:usbnet: gl620a: fix endpoint checking in genelink_bind()Syzbot reports [1] a warning in usb_submit_urb() triggered byinconsistencies between expected and actually present endpointsin gl620a driver. Since genelink_bind() does not properlyverify whether specified eps are in fact provided by the device,in this case, an artificially manufactured one, one may get amismatch.Fix the issue by resorting to a usbnet utility functionusbnet_get_endpoints(), usually reserved for this very problem.Check for endpoints and return early before proceeding further ifany are missing.[1] Syzbot report:usb 5-1: Manufacturer: syzusb 5-1: SerialNumber: syzusb 5-1: config 0 descriptor??gl620a 5-1:0.23 usb0: register &#39;gl620a&#39; at usb-dummy_hcd.0-1, ...------------[ cut here ]------------usb 5-1: BOGUS urb xfer, pipe 3 != type 1WARNING: CPU: 2 PID: 1841 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503Modules linked in:CPU: 2 UID: 0 PID: 1841 Comm: kworker/2:2 Not tainted 6.12.0-syzkaller-07834-g06afb0f36106 #0Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014Workqueue: mld mld_ifc_workRIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503...Call Trace: &lt;TASK&gt; usbnet_start_xmit+0x6be/0x2780 drivers/net/usb/usbnet.c:1467 __netdev_start_xmit include/linux/netdevice.h:5002 [inline] netdev_start_xmit include/linux/netdevice.h:5011 [inline] xmit_one net/core/dev.c:3590 [inline] dev_hard_start_xmit+0x9a/0x7b0 net/core/dev.c:3606 sch_direct_xmit+0x1ae/0xc30 net/sched/sch_generic.c:343 __dev_xmit_skb net/core/dev.c:3827 [inline] __dev_queue_xmit+0x13d4/0x43e0 net/core/dev.c:4400 dev_queue_xmit include/linux/netdevice.h:3168 [inline] neigh_resolve_output net/core/neighbour.c:1514 [inline] neigh_resolve_output+0x5bc/0x950 net/core/neighbour.c:1494 neigh_output include/net/neighbour.h:539 [inline] ip6_finish_output2+0xb1b/0x2070 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0x3f9/0x1360 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x1f8/0x540 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:450 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] NF_HOOK include/linux/netfilter.h:308 [inline] mld_sendpack+0x9f0/0x11d0 net/ipv6/mcast.c:1819 mld_send_cr net/ipv6/mcast.c:2120 [inline] mld_ifc_work+0x740/0xca0 net/ipv6/mcast.c:2651 process_one_work+0x9c5/0x1ba0 kernel/workqueue.c:3229 process_scheduled_works kernel/workqueue.c:3310 [inline] worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391 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 &lt;/TASK&gt;(CVE-2025-21877)In the Linux kernel, the following vulnerability has been resolved:ftrace: Avoid potential division by zero in function_stat_show()Check whether denominator expression x * (x - 1) * 1000 mod {2^32, 2^64}produce zero and skip stddev computation in that case.For now don&#39;t care about rec-&gt;counter * rec-&gt;counter overflow becauserec-&gt;time * rec-&gt;time overflow will likely happen earlier.(CVE-2025-21898)In the Linux kernel, the following vulnerability has been resolved:rapidio: add check for rio_add_net() in rio_scan_alloc_net()The return value of rio_add_net() should be checked.  If it fails,put_device() should be called to free the memory and give up the referenceinitialized in rio_add_net().(CVE-2025-21935)In the Linux kernel, the following vulnerability has been resolved:iscsi_ibft: Fix UBSAN shift-out-of-bounds warning in ibft_attr_show_nic()When performing an iSCSI boot using IPv6, iscsistart still reads the/sys/firmware/ibft/ethernetX/subnet-mask entry. Since the IPv6 prefixlength is 64, this causes the shift exponent to become negative,triggering a UBSAN warning. As the concept of a subnet mask does notapply to IPv6, the value is set to ~0 to suppress the warning message.(CVE-2025-21993)In the Linux kernel, the following vulnerability has been resolved:tracing: Fix use-after-free in print_graph_function_flags during tracer switchingKairui reported a UAF issue in print_graph_function_flags() duringftrace stress testing [1]. This issue can be reproduced if puting a&#39;mdelay(10)&#39; after &#39;mutex_unlock(&amp;trace_types_lock)&#39; in s_start(),and executing the following script:  $ echo function_graph &gt; current_tracer  $ cat trace &gt; /dev/null &amp;  $ sleep 5  # Ensure the &#39;cat&#39; reaches the &#39;mdelay(10)&#39; point  $ echo timerlat &gt; current_tracerThe root cause lies in the two calls to print_graph_function_flagswithin print_trace_line during each s_show():  * One through &#39;iter-&gt;trace-&gt;print_line()&#39;;  * Another through &#39;event-&gt;funcs-&gt;trace()&#39;, which is hidden in    print_trace_fmt() before print_trace_line returns.Tracer switching only updates the former, while the latter continuesto use the print_line function of the old tracer, which in the scriptabove is print_graph_function_flags.Moreover, when switching from the &#39;function_graph&#39; tracer to the&#39;timerlat&#39; tracer, s_start only calls graph_trace_close of the&#39;function_graph&#39; tracer to free &#39;iter-&gt;private&#39;, but does not setit to NULL. This provides an opportunity for &#39;event-&gt;funcs-&gt;trace()&#39;to use an invalid &#39;iter-&gt;private&#39;.To fix this issue, set &#39;iter-&gt;private&#39; to NULL immediately afterfreeing it in graph_trace_close(), ensuring that an invalid pointeris not passed to other tracers. Additionally, clean up the unnecessary&#39;iter-&gt;private = NULL&#39; during each &#39;cat trace&#39; when using wakeup andirqsoff tracers. [1] https://lore.kernel.org/all/20231112150030.84609-1-ryncsn@gmail.com/(CVE-2025-22035)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="bpftool" release="261.0.0.164.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-261.0.0.164.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="261.0.0.164.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-261.0.0.164.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="261.0.0.164.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-261.0.0.164.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="261.0.0.164.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-261.0.0.164.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="261.0.0.164.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-261.0.0.164.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="261.0.0.164.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-261.0.0.164.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="261.0.0.164.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-261.0.0.164.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="261.0.0.164.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-261.0.0.164.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="261.0.0.164.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-261.0.0.164.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="261.0.0.164.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-261.0.0.164.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="261.0.0.164.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-261.0.0.164.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="261.0.0.164.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-261.0.0.164.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="261.0.0.164.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-261.0.0.164.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="261.0.0.164.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-261.0.0.164.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="261.0.0.164.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-261.0.0.164.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="261.0.0.164.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-261.0.0.164.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="261.0.0.164.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-261.0.0.164.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="261.0.0.164.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-261.0.0.164.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="261.0.0.164.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-261.0.0.164.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="261.0.0.164.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-261.0.0.164.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="261.0.0.164.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-261.0.0.164.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="261.0.0.164.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-261.0.0.164.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="261.0.0.164.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-261.0.0.164.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="261.0.0.164.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-261.0.0.164.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="261.0.0.164.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-261.0.0.164.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="261.0.0.164.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-261.0.0.164.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="261.0.0.164.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-261.0.0.164.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="261.0.0.164.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-261.0.0.164.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="261.0.0.164.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-261.0.0.164.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="261.0.0.164.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-261.0.0.164.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1452</id>
          <title>An update for grub2 is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-04-25"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-49504" id="CVE-2024-49504" title="CVE-2024-49504" type="cve"></reference>
          </references>
          <description>grub2 allowed attackers with access to the grub shell to access files on the encrypted disks.(CVE-2024-49504)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="grub2-debuginfo" release="52.oe2203sp4" version="2.06">
                         <filename>grub2-debuginfo-2.06-52.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="grub2-debugsource" release="52.oe2203sp4" version="2.06">
                         <filename>grub2-debugsource-2.06-52.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="grub2-efi-aa64" release="52.oe2203sp4" version="2.06">
                         <filename>grub2-efi-aa64-2.06-52.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="grub2-efi-aa64-cdboot" release="52.oe2203sp4" version="2.06">
                         <filename>grub2-efi-aa64-cdboot-2.06-52.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="grub2-tools" release="52.oe2203sp4" version="2.06">
                         <filename>grub2-tools-2.06-52.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="grub2-tools-extra" release="52.oe2203sp4" version="2.06">
                         <filename>grub2-tools-extra-2.06-52.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="grub2-tools-minimal" release="52.oe2203sp4" version="2.06">
                         <filename>grub2-tools-minimal-2.06-52.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="grub2-common" release="52.oe2203sp4" version="2.06">
                         <filename>grub2-common-2.06-52.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="grub2-efi-aa64-modules" release="52.oe2203sp4" version="2.06">
                         <filename>grub2-efi-aa64-modules-2.06-52.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="grub2-efi-ia32-modules" release="52.oe2203sp4" version="2.06">
                         <filename>grub2-efi-ia32-modules-2.06-52.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="grub2-efi-x64-modules" release="52.oe2203sp4" version="2.06">
                         <filename>grub2-efi-x64-modules-2.06-52.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="grub2-help" release="52.oe2203sp4" version="2.06">
                         <filename>grub2-help-2.06-52.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="grub2-pc-modules" release="52.oe2203sp4" version="2.06">
                         <filename>grub2-pc-modules-2.06-52.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-debuginfo" release="52.oe2203sp4" version="2.06">
                         <filename>grub2-debuginfo-2.06-52.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-debugsource" release="52.oe2203sp4" version="2.06">
                         <filename>grub2-debugsource-2.06-52.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-efi-ia32" release="52.oe2203sp4" version="2.06">
                         <filename>grub2-efi-ia32-2.06-52.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-efi-ia32-cdboot" release="52.oe2203sp4" version="2.06">
                         <filename>grub2-efi-ia32-cdboot-2.06-52.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-efi-x64" release="52.oe2203sp4" version="2.06">
                         <filename>grub2-efi-x64-2.06-52.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-efi-x64-cdboot" release="52.oe2203sp4" version="2.06">
                         <filename>grub2-efi-x64-cdboot-2.06-52.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-pc" release="52.oe2203sp4" version="2.06">
                         <filename>grub2-pc-2.06-52.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-tools" release="52.oe2203sp4" version="2.06">
                         <filename>grub2-tools-2.06-52.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-tools-efi" release="52.oe2203sp4" version="2.06">
                         <filename>grub2-tools-efi-2.06-52.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-tools-extra" release="52.oe2203sp4" version="2.06">
                         <filename>grub2-tools-extra-2.06-52.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-tools-minimal" release="52.oe2203sp4" version="2.06">
                         <filename>grub2-tools-minimal-2.06-52.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1453</id>
          <title>An update for raptor2 is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2025-04-25"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57823" id="CVE-2024-57823" title="CVE-2024-57823" type="cve"></reference>
          </references>
          <description>In Raptor RDF Syntax Library through 2.0.16, there is an integer underflow when normalizing a URI with the turtle parser in raptor_uri_normalize_path().(CVE-2024-57823)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="raptor2" release="19.oe2203sp4" version="2.0.15">
                         <filename>raptor2-2.0.15-19.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="raptor2-debuginfo" release="19.oe2203sp4" version="2.0.15">
                         <filename>raptor2-debuginfo-2.0.15-19.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="raptor2-debugsource" release="19.oe2203sp4" version="2.0.15">
                         <filename>raptor2-debugsource-2.0.15-19.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="raptor2-devel" release="19.oe2203sp4" version="2.0.15">
                         <filename>raptor2-devel-2.0.15-19.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="raptor2-help" release="19.oe2203sp4" version="2.0.15">
                         <filename>raptor2-help-2.0.15-19.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="raptor2" release="19.oe2203sp4" version="2.0.15">
                         <filename>raptor2-2.0.15-19.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="raptor2-debuginfo" release="19.oe2203sp4" version="2.0.15">
                         <filename>raptor2-debuginfo-2.0.15-19.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="raptor2-debugsource" release="19.oe2203sp4" version="2.0.15">
                         <filename>raptor2-debugsource-2.0.15-19.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="raptor2-devel" release="19.oe2203sp4" version="2.0.15">
                         <filename>raptor2-devel-2.0.15-19.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="raptor2-help" release="19.oe2203sp4" version="2.0.15">
                         <filename>raptor2-help-2.0.15-19.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1454</id>
          <title>An update for mysql is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-04-25"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21574" id="CVE-2025-21574" title="CVE-2025-21574" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21575" id="CVE-2025-21575" title="CVE-2025-21575" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21577" id="CVE-2025-21577" title="CVE-2025-21577" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21579" id="CVE-2025-21579" title="CVE-2025-21579" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21580" id="CVE-2025-21580" title="CVE-2025-21580" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21581" id="CVE-2025-21581" title="CVE-2025-21581" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21584" id="CVE-2025-21584" title="CVE-2025-21584" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21585" id="CVE-2025-21585" title="CVE-2025-21585" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30681" id="CVE-2025-30681" title="CVE-2025-30681" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30682" id="CVE-2025-30682" title="CVE-2025-30682" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30683" id="CVE-2025-30683" title="CVE-2025-30683" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30684" id="CVE-2025-30684" title="CVE-2025-30684" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30685" id="CVE-2025-30685" title="CVE-2025-30685" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30687" id="CVE-2025-30687" title="CVE-2025-30687" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30688" id="CVE-2025-30688" title="CVE-2025-30688" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30689" id="CVE-2025-30689" title="CVE-2025-30689" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30693" id="CVE-2025-30693" title="CVE-2025-30693" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30695" id="CVE-2025-30695" title="CVE-2025-30695" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30696" id="CVE-2025-30696" title="CVE-2025-30696" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30699" id="CVE-2025-30699" title="CVE-2025-30699" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30703" id="CVE-2025-30703" title="CVE-2025-30703" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30704" id="CVE-2025-30704" title="CVE-2025-30704" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30705" id="CVE-2025-30705" title="CVE-2025-30705" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30710" id="CVE-2025-30710" title="CVE-2025-30710" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30715" id="CVE-2025-30715" title="CVE-2025-30715" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30721" id="CVE-2025-30721" title="CVE-2025-30721" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30722" id="CVE-2025-30722" title="CVE-2025-30722" type="cve"></reference>
          </references>
          <description>Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Parser).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).(CVE-2025-21574)Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Parser).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).(CVE-2025-21575)Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).(CVE-2025-21577)Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Options).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).(CVE-2025-21579)Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: DML).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).(CVE-2025-21580)Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).(CVE-2025-21581)Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: DDL).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).(CVE-2025-21584)Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).(CVE-2025-21585)Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Replication).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of MySQL Server. CVSS 3.1 Base Score 2.7 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:L).(CVE-2025-30681)Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).(CVE-2025-30682)Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Replication).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).(CVE-2025-30683)Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Replication).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).(CVE-2025-30684)Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Replication).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).(CVE-2025-30685)Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).(CVE-2025-30687)Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).(CVE-2025-30688)Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).(CVE-2025-30689)Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server as well as  unauthorized update, insert or delete access to some of MySQL Server accessible data. CVSS 3.1 Base Score 5.5 (Integrity and Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:H).(CVE-2025-30693)Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server as well as  unauthorized update, insert or delete access to some of MySQL Server accessible data. CVSS 3.1 Base Score 5.5 (Integrity and Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:H).(CVE-2025-30695)Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: PS).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).(CVE-2025-30696)Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Stored Procedure).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).(CVE-2025-30699)Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of MySQL Server accessible data. CVSS 3.1 Base Score 2.7 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:N).(CVE-2025-30703)Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Components Services).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Difficult to exploit vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.4 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H).(CVE-2025-30704)Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: PS).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).(CVE-2025-30705)Vulnerability in the MySQL Cluster product of Oracle MySQL (component: Cluster: NDBCluster Plugin).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Cluster.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Cluster. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).(CVE-2025-30710)Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Components Services).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).(CVE-2025-30715)Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: UDF).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Difficult to exploit vulnerability allows high privileged attacker with logon to the infrastructure where MySQL Server executes to compromise MySQL Server.  Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.0 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:L/AC:H/PR:H/UI:R/S:U/C:N/I:N/A:H).(CVE-2025-30721)Vulnerability in the MySQL Client product of Oracle MySQL (component: Client: mysqldump).  Supported versions that are affected are 8.0.0-8.0.41, 8.4.0-8.4.4 and  9.0.0-9.2.0. Difficult to exploit vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Client.  Successful attacks of this vulnerability can result in  unauthorized access to critical data or complete access to all MySQL Client accessible data as well as  unauthorized update, insert or delete access to some of MySQL Client accessible data. CVSS 3.1 Base Score 5.9 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:L/A:N).(CVE-2025-30722)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="mysql" release="1.oe2203sp4" version="8.0.42">
                         <filename>mysql-8.0.42-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-common" release="1.oe2203sp4" version="8.0.42">
                         <filename>mysql-common-8.0.42-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-config" release="1.oe2203sp4" version="8.0.42">
                         <filename>mysql-config-8.0.42-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-debuginfo" release="1.oe2203sp4" version="8.0.42">
                         <filename>mysql-debuginfo-8.0.42-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-debugsource" release="1.oe2203sp4" version="8.0.42">
                         <filename>mysql-debugsource-8.0.42-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-devel" release="1.oe2203sp4" version="8.0.42">
                         <filename>mysql-devel-8.0.42-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-errmsg" release="1.oe2203sp4" version="8.0.42">
                         <filename>mysql-errmsg-8.0.42-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-help" release="1.oe2203sp4" version="8.0.42">
                         <filename>mysql-help-8.0.42-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-libs" release="1.oe2203sp4" version="8.0.42">
                         <filename>mysql-libs-8.0.42-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-server" release="1.oe2203sp4" version="8.0.42">
                         <filename>mysql-server-8.0.42-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-test" release="1.oe2203sp4" version="8.0.42">
                         <filename>mysql-test-8.0.42-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql" release="1.oe2203sp4" version="8.0.42">
                         <filename>mysql-8.0.42-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-common" release="1.oe2203sp4" version="8.0.42">
                         <filename>mysql-common-8.0.42-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-config" release="1.oe2203sp4" version="8.0.42">
                         <filename>mysql-config-8.0.42-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-debuginfo" release="1.oe2203sp4" version="8.0.42">
                         <filename>mysql-debuginfo-8.0.42-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-debugsource" release="1.oe2203sp4" version="8.0.42">
                         <filename>mysql-debugsource-8.0.42-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-devel" release="1.oe2203sp4" version="8.0.42">
                         <filename>mysql-devel-8.0.42-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-errmsg" release="1.oe2203sp4" version="8.0.42">
                         <filename>mysql-errmsg-8.0.42-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-help" release="1.oe2203sp4" version="8.0.42">
                         <filename>mysql-help-8.0.42-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-libs" release="1.oe2203sp4" version="8.0.42">
                         <filename>mysql-libs-8.0.42-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-server" release="1.oe2203sp4" version="8.0.42">
                         <filename>mysql-server-8.0.42-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-test" release="1.oe2203sp4" version="8.0.42">
                         <filename>mysql-test-8.0.42-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1457</id>
          <title>An update for libxml2 is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2025-04-25"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-32415" id="CVE-2025-32415" title="CVE-2025-32415" type="cve"></reference>
          </references>
          <description>In libxml2 before 2.13.8 and 2.14.x before 2.14.2, xmlSchemaIDCFillNodeTables in xmlschemas.c has a heap-based buffer under-read. To exploit this, a crafted XML document must be validated against an XML schema with certain identity constraints, or a crafted XML schema must be used.(CVE-2025-32415)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libxml2" release="16.oe2203sp4" version="2.9.14">
                         <filename>libxml2-2.9.14-16.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libxml2-debuginfo" release="16.oe2203sp4" version="2.9.14">
                         <filename>libxml2-debuginfo-2.9.14-16.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libxml2-debugsource" release="16.oe2203sp4" version="2.9.14">
                         <filename>libxml2-debugsource-2.9.14-16.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libxml2-devel" release="16.oe2203sp4" version="2.9.14">
                         <filename>libxml2-devel-2.9.14-16.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-libxml2" release="16.oe2203sp4" version="2.9.14">
                         <filename>python3-libxml2-2.9.14-16.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="libxml2-help" release="16.oe2203sp4" version="2.9.14">
                         <filename>libxml2-help-2.9.14-16.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libxml2" release="16.oe2203sp4" version="2.9.14">
                         <filename>libxml2-2.9.14-16.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libxml2-debuginfo" release="16.oe2203sp4" version="2.9.14">
                         <filename>libxml2-debuginfo-2.9.14-16.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libxml2-debugsource" release="16.oe2203sp4" version="2.9.14">
                         <filename>libxml2-debugsource-2.9.14-16.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libxml2-devel" release="16.oe2203sp4" version="2.9.14">
                         <filename>libxml2-devel-2.9.14-16.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-libxml2" release="16.oe2203sp4" version="2.9.14">
                         <filename>python3-libxml2-2.9.14-16.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1460</id>
          <title>An update for libsoup is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2025-04-25"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-32906" id="CVE-2025-32906" title="CVE-2025-32906" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-32909" id="CVE-2025-32909" title="CVE-2025-32909" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-32910" id="CVE-2025-32910" title="CVE-2025-32910" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-32911" id="CVE-2025-32911" title="CVE-2025-32911" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-32912" id="CVE-2025-32912" title="CVE-2025-32912" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-32913" id="CVE-2025-32913" title="CVE-2025-32913" type="cve"></reference>
          </references>
          <description>A flaw was found in libsoup, where the soup_headers_parse_request() function may be vulnerable to an out-of-bound read. This flaw allows a malicious user to use a specially crafted HTTP request to crash the HTTP server.(CVE-2025-32906)A flaw was found in libsoup. SoupContentSniffer may be vulnerable to a NULL pointer dereference in the sniff_mp4 function. The HTTP server may cause the libsoup client to crash.(CVE-2025-32909)A flaw was found in libsoup, where soup_auth_digest_authenticate() is vulnerable to a NULL pointer dereference. This issue may cause the libsoup client to crash.(CVE-2025-32910)A flaw was found in libsoup, which is vulnerable to a use-after-free memory issue not on the heap in the soup_message_headers_get_content_disposition() function. This flaw allows a malicious HTTP client to cause memory corruption in the libsoup server.(CVE-2025-32911)A flaw was found in libsoup, where SoupAuthDigest is vulnerable to a NULL pointer dereference. The HTTP server may cause the libsoup client to crash.(CVE-2025-32912)A flaw was found in libsoup, where the soup_message_headers_get_content_disposition() function is vulnerable to a NULL pointer dereference. This flaw allows a malicious HTTP peer to crash a libsoup client or server that uses this function.(CVE-2025-32913)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libsoup" release="7.oe2203sp4" version="2.74.2">
                         <filename>libsoup-2.74.2-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libsoup-debuginfo" release="7.oe2203sp4" version="2.74.2">
                         <filename>libsoup-debuginfo-2.74.2-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libsoup-debugsource" release="7.oe2203sp4" version="2.74.2">
                         <filename>libsoup-debugsource-2.74.2-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libsoup-devel" release="7.oe2203sp4" version="2.74.2">
                         <filename>libsoup-devel-2.74.2-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="libsoup-help" release="7.oe2203sp4" version="2.74.2">
                         <filename>libsoup-help-2.74.2-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libsoup" release="7.oe2203sp4" version="2.74.2">
                         <filename>libsoup-2.74.2-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libsoup-debuginfo" release="7.oe2203sp4" version="2.74.2">
                         <filename>libsoup-debuginfo-2.74.2-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libsoup-debugsource" release="7.oe2203sp4" version="2.74.2">
                         <filename>libsoup-debugsource-2.74.2-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libsoup-devel" release="7.oe2203sp4" version="2.74.2">
                         <filename>libsoup-devel-2.74.2-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1461</id>
          <title>An update for erlang is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2025-04-29"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-32433" id="CVE-2025-32433" title="CVE-2025-32433" type="cve"></reference>
          </references>
          <description></description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="erlang" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-asn1" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-asn1-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-common_test" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-common_test-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-compiler" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-compiler-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-crypto" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-crypto-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-debugger" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-debugger-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-debuginfo" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-debuginfo-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-debugsource" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-debugsource-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-dialyzer" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-dialyzer-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-diameter" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-diameter-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-edoc" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-edoc-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-eldap" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-eldap-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-erl_docgen" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-erl_docgen-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-erl_interface" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-erl_interface-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-erts" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-erts-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-et" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-et-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-eunit" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-eunit-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-examples" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-examples-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-ftp" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-ftp-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-hipe" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-hipe-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-inets" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-inets-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-jinterface" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-jinterface-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-kernel" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-kernel-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-megaco" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-megaco-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-mnesia" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-mnesia-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-observer" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-observer-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-odbc" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-odbc-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-os_mon" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-os_mon-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-parsetools" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-parsetools-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-public_key" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-public_key-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-reltool" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-reltool-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-runtime_tools" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-runtime_tools-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-sasl" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-sasl-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-snmp" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-snmp-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-ssh" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-ssh-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-ssl" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-ssl-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-stdlib" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-stdlib-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-syntax_tools" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-syntax_tools-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-tftp" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-tftp-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-tools" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-tools-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-wx" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-wx-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-xmerl" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-xmerl-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-asn1" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-asn1-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-common_test" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-common_test-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-compiler" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-compiler-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-crypto" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-crypto-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-debugger" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-debugger-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-debuginfo" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-debuginfo-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-debugsource" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-debugsource-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-dialyzer" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-dialyzer-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-diameter" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-diameter-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-edoc" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-edoc-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-eldap" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-eldap-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-erl_docgen" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-erl_docgen-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-erl_interface" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-erl_interface-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-erts" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-erts-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-et" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-et-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-eunit" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-eunit-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-examples" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-examples-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-ftp" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-ftp-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-hipe" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-hipe-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-inets" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-inets-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-jinterface" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-jinterface-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-kernel" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-kernel-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-megaco" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-megaco-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-mnesia" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-mnesia-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-observer" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-observer-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-odbc" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-odbc-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-os_mon" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-os_mon-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-parsetools" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-parsetools-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-public_key" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-public_key-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-reltool" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-reltool-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-runtime_tools" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-runtime_tools-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-sasl" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-sasl-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-snmp" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-snmp-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-ssh" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-ssh-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-ssl" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-ssl-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-stdlib" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-stdlib-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-syntax_tools" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-syntax_tools-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-tftp" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-tftp-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-tools" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-tools-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-wx" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-wx-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-xmerl" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-xmerl-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1462</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-05-09"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-58094" id="CVE-2024-58094" title="CVE-2024-58094" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21760" id="CVE-2025-21760" title="CVE-2025-21760" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21761" id="CVE-2025-21761" title="CVE-2025-21761" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21762" id="CVE-2025-21762" title="CVE-2025-21762" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21763" id="CVE-2025-21763" title="CVE-2025-21763" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21764" id="CVE-2025-21764" title="CVE-2025-21764" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:jfs: add check read-only before truncation in jfs_truncate_nolock()Added a check for &#34;read-only&#34; mode in the `jfs_truncate_nolock`function to avoid errors related to writing to a read-onlyfilesystem.Call stack:block_write_begin() {  jfs_write_failed() {    jfs_truncate() {      jfs_truncate_nolock() {        txEnd() {          ...          log = JFS_SBI(tblk-&gt;sb)-&gt;log;          // (log == NULL)If the `isReadOnly(ip)` condition is triggered in`jfs_truncate_nolock`, the function execution will stop, and nofurther data modification will occur. Instead, the `xtTruncate`function will be called with the &#34;COMMIT_WMAP&#34; flag, preventingmodifications in &#34;read-only&#34; mode.(CVE-2024-58094)In the Linux kernel, the following vulnerability has been resolved:ndisc: extend RCU protection in ndisc_send_skb()ndisc_send_skb() can be called without RTNL or RCU held.Acquire rcu_read_lock() earlier, so that we can use dev_net_rcu()and avoid a potential UAF.(CVE-2025-21760)In the Linux kernel, the following vulnerability has been resolved:openvswitch: use RCU protection in ovs_vport_cmd_fill_info()ovs_vport_cmd_fill_info() can be called without RTNL or RCU.Use RCU protection and dev_net_rcu() to avoid potential UAF.(CVE-2025-21761)In the Linux kernel, the following vulnerability has been resolved:arp: use RCU protection in arp_xmit()arp_xmit() can be called without RTNL or RCU protection.Use RCU protection to avoid potential UAF.(CVE-2025-21762)In the Linux kernel, the following vulnerability has been resolved:neighbour: use RCU protection in __neigh_notify()__neigh_notify() can be called without RTNL or RCU protection.Use RCU protection to avoid potential UAF.(CVE-2025-21763)In the Linux kernel, the following vulnerability has been resolved:ndisc: use RCU protection in ndisc_alloc_skb()ndisc_alloc_skb() can be called without RTNL or RCU being held.Add RCU protection to avoid possible UAF.(CVE-2025-21764)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="bpftool" release="262.0.0.165.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-262.0.0.165.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="262.0.0.165.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-262.0.0.165.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="262.0.0.165.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-262.0.0.165.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="262.0.0.165.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-262.0.0.165.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="262.0.0.165.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-262.0.0.165.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="262.0.0.165.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-262.0.0.165.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="262.0.0.165.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-262.0.0.165.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="262.0.0.165.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-262.0.0.165.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="262.0.0.165.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-262.0.0.165.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="262.0.0.165.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-262.0.0.165.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="262.0.0.165.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-262.0.0.165.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="262.0.0.165.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-262.0.0.165.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="262.0.0.165.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-262.0.0.165.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="262.0.0.165.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-262.0.0.165.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="262.0.0.165.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-262.0.0.165.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="262.0.0.165.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-262.0.0.165.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="262.0.0.165.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-262.0.0.165.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="262.0.0.165.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-262.0.0.165.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="262.0.0.165.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-262.0.0.165.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="262.0.0.165.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-262.0.0.165.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="262.0.0.165.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-262.0.0.165.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="262.0.0.165.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-262.0.0.165.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="262.0.0.165.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-262.0.0.165.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="262.0.0.165.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-262.0.0.165.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="262.0.0.165.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-262.0.0.165.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="262.0.0.165.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-262.0.0.165.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="262.0.0.165.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-262.0.0.165.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="262.0.0.165.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-262.0.0.165.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="262.0.0.165.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-262.0.0.165.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="262.0.0.165.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-262.0.0.165.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1468</id>
          <title>An update for cobbler is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2025-05-09"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-40323" id="CVE-2021-40323" title="CVE-2021-40323" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-40324" id="CVE-2021-40324" title="CVE-2021-40324" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-45081" id="CVE-2021-45081" title="CVE-2021-45081" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-45082" id="CVE-2021-45082" title="CVE-2021-45082" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-45083" id="CVE-2021-45083" title="CVE-2021-45083" type="cve"></reference>
          </references>
          <description>Cobbler before 3.3.0 allows log poisoning, and resultant Remote Code Execution, via an XMLRPC method that logs to the logfile for template injection.(CVE-2021-40323)Cobbler before 3.3.0 allows arbitrary file write operations via upload_log_data.(CVE-2021-40324)An issue was discovered in Cobbler through 3.3.1. Routines in several files use the HTTP protocol instead of the more secure HTTPS.(CVE-2021-45081)An issue was discovered in Cobbler before 3.3.1. In the templar.py file, the function check_for_invalid_imports can allow Cheetah code to import Python modules via the &#34;#from MODULE import&#34; substring. (Only lines beginning with #import are blocked.)(CVE-2021-45082)An issue was discovered in Cobbler before 3.3.1. Files in /etc/cobbler are world readable. Two of those files contain some sensitive information that can be exposed to a local user who has non-privileged access to the server. The users.digest file contains the sha2-512 digest of users in a Cobbler local installation. In the case of an easy-to-guess password, it&#39;s trivial to obtain the plaintext string. The settings.yaml file contains secrets such as the hashed default password.(CVE-2021-45083)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="cobbler" release="2.oe2203sp4" version="3.2.3">
                         <filename>cobbler-3.2.3-2.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="cobbler-web" release="2.oe2203sp4" version="3.2.3">
                         <filename>cobbler-web-3.2.3-2.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1473</id>
          <title>An update for perl is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2025-05-09"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-56406" id="CVE-2024-56406" title="CVE-2024-56406" type="cve"></reference>
          </references>
          <description>A heap buffer overflow vulnerability was discovered in Perl. Release branches 5.34, 5.36, 5.38 and 5.40 are affected, including development versions from 5.33.1 through 5.41.10.When there are non-ASCII bytes in the left-hand-side of the `tr` operator, `S_do_trans_invmap` can overflow the destination pointer `d`.   $ perl -e &#39;$_ = &#34;\x{FF}&#34; x 1000000; tr/\xFF/\x{100}/;&#39;    Segmentation fault (core dumped)It is believed that this vulnerability can enable Denial of Service and possibly Code Execution attacks on platforms that lack sufficient defenses.(CVE-2024-56406)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="4" arch="aarch64" name="perl" release="13.oe2203sp4" version="5.34.0">
                         <filename>perl-5.34.0-13.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="4" arch="aarch64" name="perl-debuginfo" release="13.oe2203sp4" version="5.34.0">
                         <filename>perl-debuginfo-5.34.0-13.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="4" arch="aarch64" name="perl-debugsource" release="13.oe2203sp4" version="5.34.0">
                         <filename>perl-debugsource-5.34.0-13.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="4" arch="aarch64" name="perl-devel" release="13.oe2203sp4" version="5.34.0">
                         <filename>perl-devel-5.34.0-13.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="4" arch="aarch64" name="perl-libs" release="13.oe2203sp4" version="5.34.0">
                         <filename>perl-libs-5.34.0-13.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="4" arch="noarch" name="perl-help" release="13.oe2203sp4" version="5.34.0">
                         <filename>perl-help-5.34.0-13.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="4" arch="x86_64" name="perl" release="13.oe2203sp4" version="5.34.0">
                         <filename>perl-5.34.0-13.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="4" arch="x86_64" name="perl-debuginfo" release="13.oe2203sp4" version="5.34.0">
                         <filename>perl-debuginfo-5.34.0-13.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="4" arch="x86_64" name="perl-debugsource" release="13.oe2203sp4" version="5.34.0">
                         <filename>perl-debugsource-5.34.0-13.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="4" arch="x86_64" name="perl-devel" release="13.oe2203sp4" version="5.34.0">
                         <filename>perl-devel-5.34.0-13.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="4" arch="x86_64" name="perl-libs" release="13.oe2203sp4" version="5.34.0">
                         <filename>perl-libs-5.34.0-13.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1474</id>
          <title>An update for redis is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-05-09"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21605" id="CVE-2025-21605" title="CVE-2025-21605" type="cve"></reference>
          </references>
          <description>Redis is an open source, in-memory database that persists on disk. In versions starting at 2.6 and prior to 7.4.3, An unauthenticated client can cause unlimited growth of output buffers, until the server runs out of memory or is killed. By default, the Redis configuration does not limit the output buffer of normal clients (see client-output-buffer-limit). Therefore, the output buffer can grow unlimitedly over time. As a result, the service is exhausted and the memory is unavailable. When password authentication is enabled on the Redis server, but no password is provided, the client can still cause the output buffer to grow from &#34;NOAUTH&#34; responses until the system will run out of memory. This issue has been patched in version 7.4.3. An additional workaround to mitigate this problem without patching the redis-server executable is to block access to prevent unauthenticated users from connecting to Redis. This can be done in different ways. Either using network access control tools like firewalls, iptables, security groups, etc, or enabling TLS and requiring users to authenticate using client side certificates.(CVE-2025-21605)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="redis" release="1.oe2203sp4" version="7.2.8">
                         <filename>redis-7.2.8-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="redis-debuginfo" release="1.oe2203sp4" version="7.2.8">
                         <filename>redis-debuginfo-7.2.8-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="redis-debugsource" release="1.oe2203sp4" version="7.2.8">
                         <filename>redis-debugsource-7.2.8-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="redis" release="1.oe2203sp4" version="7.2.8">
                         <filename>redis-7.2.8-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="redis-debuginfo" release="1.oe2203sp4" version="7.2.8">
                         <filename>redis-debuginfo-7.2.8-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="redis-debugsource" release="1.oe2203sp4" version="7.2.8">
                         <filename>redis-debugsource-7.2.8-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1475</id>
          <title>An update for fcgi is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2025-05-09"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-23016" id="CVE-2025-23016" title="CVE-2025-23016" type="cve"></reference>
          </references>
          <description>FastCGI fcgi2 (aka fcgi) 2.x through 2.4.4 has an integer overflow (and resultant heap-based buffer overflow) via crafted nameLen or valueLen values in data to the IPC socket. This occurs in ReadParams in fcgiapp.c.(CVE-2025-23016)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="fcgi" release="2.oe2203sp4" version="2.4.2">
                         <filename>fcgi-2.4.2-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="fcgi-debuginfo" release="2.oe2203sp4" version="2.4.2">
                         <filename>fcgi-debuginfo-2.4.2-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="fcgi-debugsource" release="2.oe2203sp4" version="2.4.2">
                         <filename>fcgi-debugsource-2.4.2-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="fcgi-devel" release="2.oe2203sp4" version="2.4.2">
                         <filename>fcgi-devel-2.4.2-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="fcgi" release="2.oe2203sp4" version="2.4.2">
                         <filename>fcgi-2.4.2-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="fcgi-debuginfo" release="2.oe2203sp4" version="2.4.2">
                         <filename>fcgi-debuginfo-2.4.2-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="fcgi-debugsource" release="2.oe2203sp4" version="2.4.2">
                         <filename>fcgi-debugsource-2.4.2-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="fcgi-devel" release="2.oe2203sp4" version="2.4.2">
                         <filename>fcgi-devel-2.4.2-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1478</id>
          <title>An update for LibRaw is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2025-05-09"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-43961" id="CVE-2025-43961" title="CVE-2025-43961" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-43962" id="CVE-2025-43962" title="CVE-2025-43962" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-43963" id="CVE-2025-43963" title="CVE-2025-43963" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-43964" id="CVE-2025-43964" title="CVE-2025-43964" type="cve"></reference>
          </references>
          <description>In LibRaw before 0.21.4, metadata/tiff.cpp has an out-of-bounds read in the Fujifilm 0xf00c tag parser.(CVE-2025-43961)In LibRaw before 0.21.4, phase_one_correct in decoders/load_mfbacks.cpp has out-of-bounds reads for tag 0x412 processing, related to large w0 or w1 values or the frac and mult calculations.(CVE-2025-43962)In LibRaw before 0.21.4, phase_one_correct in decoders/load_mfbacks.cpp allows out-of-buffer access because split_col and split_row values are not checked in 0x041f tag processing.(CVE-2025-43963)In LibRaw before 0.21.4, tag 0x412 processing in phase_one_correct in decoders/load_mfbacks.cpp does not enforce minimum w0 and w1 values.(CVE-2025-43964)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="LibRaw" release="9.oe2203sp4" version="0.20.2">
                         <filename>LibRaw-0.20.2-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="LibRaw-debuginfo" release="9.oe2203sp4" version="0.20.2">
                         <filename>LibRaw-debuginfo-0.20.2-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="LibRaw-debugsource" release="9.oe2203sp4" version="0.20.2">
                         <filename>LibRaw-debugsource-0.20.2-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="LibRaw-devel" release="9.oe2203sp4" version="0.20.2">
                         <filename>LibRaw-devel-0.20.2-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="LibRaw" release="9.oe2203sp4" version="0.20.2">
                         <filename>LibRaw-0.20.2-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="LibRaw-debuginfo" release="9.oe2203sp4" version="0.20.2">
                         <filename>LibRaw-debuginfo-0.20.2-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="LibRaw-debugsource" release="9.oe2203sp4" version="0.20.2">
                         <filename>LibRaw-debugsource-0.20.2-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="LibRaw-devel" release="9.oe2203sp4" version="0.20.2">
                         <filename>LibRaw-devel-0.20.2-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1479</id>
          <title>An update for ppp is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2025-05-09"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-58250" id="CVE-2024-58250" title="CVE-2024-58250" type="cve"></reference>
          </references>
          <description>The passprompt plugin in pppd in ppp before 2.5.2 mishandles privileges.(CVE-2024-58250)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="ppp" release="8.oe2203sp4" version="2.4.9">
                         <filename>ppp-2.4.9-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ppp-debuginfo" release="8.oe2203sp4" version="2.4.9">
                         <filename>ppp-debuginfo-2.4.9-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ppp-debugsource" release="8.oe2203sp4" version="2.4.9">
                         <filename>ppp-debugsource-2.4.9-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ppp-devel" release="8.oe2203sp4" version="2.4.9">
                         <filename>ppp-devel-2.4.9-8.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="ppp-help" release="8.oe2203sp4" version="2.4.9">
                         <filename>ppp-help-2.4.9-8.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ppp" release="8.oe2203sp4" version="2.4.9">
                         <filename>ppp-2.4.9-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ppp-debuginfo" release="8.oe2203sp4" version="2.4.9">
                         <filename>ppp-debuginfo-2.4.9-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ppp-debugsource" release="8.oe2203sp4" version="2.4.9">
                         <filename>ppp-debugsource-2.4.9-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ppp-devel" release="8.oe2203sp4" version="2.4.9">
                         <filename>ppp-devel-2.4.9-8.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1484</id>
          <title>An update for tomcat is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2025-05-09"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-31650" id="CVE-2025-31650" title="CVE-2025-31650" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-31651" id="CVE-2025-31651" title="CVE-2025-31651" type="cve"></reference>
          </references>
          <description>Improper Input Validation vulnerability in Apache Tomcat. Incorrect error handling for some invalid HTTP priority headers resulted in incomplete clean-up of the failed request which created a memory leak. A large number of such requests could trigger an OutOfMemoryException resulting in a denial of service.This issue affects Apache Tomcat: from 9.0.76 through 9.0.102, from 10.1.10 through 10.1.39, from 11.0.0-M2 through 11.0.5.Users are recommended to upgrade to version 9.0.104, 10.1.40 or 11.0.6 which fix the issue.(CVE-2025-31650)Improper Neutralization of Escape, Meta, or Control Sequences vulnerability in Apache Tomcat. For a subset of unlikely rewrite rule configurations, it was possible for a specially crafted request to bypass some rewrite rules. If those rewrite rules effectively enforced security constraints, those constraints could be bypassed.This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.5, from 10.1.0-M1 through 10.1.39, from 9.0.0.M1 through 9.0.102.Users are recommended to upgrade to version [FIXED_VERSION], which fixes the issue.(CVE-2025-31651)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="noarch" name="tomcat" release="2.oe2203sp4" version="9.0.100">
                         <filename>tomcat-9.0.100-2.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="tomcat-help" release="2.oe2203sp4" version="9.0.100">
                         <filename>tomcat-help-9.0.100-2.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="tomcat-jsvc" release="2.oe2203sp4" version="9.0.100">
                         <filename>tomcat-jsvc-9.0.100-2.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1485</id>
          <title>An update for libsoup is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-05-09"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-32907" id="CVE-2025-32907" title="CVE-2025-32907" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-32914" id="CVE-2025-32914" title="CVE-2025-32914" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-46420" id="CVE-2025-46420" title="CVE-2025-46420" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-46421" id="CVE-2025-46421" title="CVE-2025-46421" type="cve"></reference>
          </references>
          <description>A flaw was found in libsoup. The implementation of HTTP range requests is vulnerable to a resource consumption attack. This flaw allows a malicious client to request the same range many times in a single HTTP request, causing the server to use large amounts of memory.(CVE-2025-32907)A flaw was found in libsoup, where the soup_multipart_new_from_message() function is vulnerable to an out-of-bounds read. This flaw allows a malicious HTTP client to induce the libsoup server to read out of bounds.(CVE-2025-32914)A flaw was found in libsoup. It is vulnerable to memory leaks in the soup_header_parse_quality_list() function when parsing a quality list that contains elements with all zeroes.(CVE-2025-46420)A flaw was found in libsoup. When libsoup clients encounter an HTTP redirect, they mistakenly send the HTTP Authorization header to the new host that the redirection points to. This allows the new host to impersonate the user to the original host that issued the redirect.(CVE-2025-46421)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libsoup" release="9.oe2203sp4" version="2.74.2">
                         <filename>libsoup-2.74.2-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libsoup-debuginfo" release="9.oe2203sp4" version="2.74.2">
                         <filename>libsoup-debuginfo-2.74.2-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libsoup-debugsource" release="9.oe2203sp4" version="2.74.2">
                         <filename>libsoup-debugsource-2.74.2-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libsoup-devel" release="9.oe2203sp4" version="2.74.2">
                         <filename>libsoup-devel-2.74.2-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="libsoup-help" release="9.oe2203sp4" version="2.74.2">
                         <filename>libsoup-help-2.74.2-9.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libsoup" release="9.oe2203sp4" version="2.74.2">
                         <filename>libsoup-2.74.2-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libsoup-debuginfo" release="9.oe2203sp4" version="2.74.2">
                         <filename>libsoup-debuginfo-2.74.2-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libsoup-debugsource" release="9.oe2203sp4" version="2.74.2">
                         <filename>libsoup-debugsource-2.74.2-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libsoup-devel" release="9.oe2203sp4" version="2.74.2">
                         <filename>libsoup-devel-2.74.2-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1489</id>
          <title>An update for firefox is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-05-09"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-2817" id="CVE-2025-2817" title="CVE-2025-2817" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-4083" id="CVE-2025-4083" title="CVE-2025-4083" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-4084" id="CVE-2025-4084" title="CVE-2025-4084" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-4087" id="CVE-2025-4087" title="CVE-2025-4087" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-4091" id="CVE-2025-4091" title="CVE-2025-4091" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-4093" id="CVE-2025-4093" title="CVE-2025-4093" type="cve"></reference>
          </references>
          <description>Thunderbird&#39;s update mechanism allowed a medium-integrity user process to interfere with the SYSTEM-level updater by manipulating the file-locking behavior. By injecting code into the user-privileged process, an attacker could bypass intended access controls, allowing SYSTEM-level file operations on paths controlled by a non-privileged user and enabling privilege escalation. This vulnerability affects Firefox &lt; 138, Firefox ESR &lt; 128.10, Firefox ESR &lt; 115.23, Thunderbird &lt; 138, and Thunderbird &lt; 128.10.(CVE-2025-2817)A process isolation vulnerability in Thunderbird stemmed from improper handling of javascript: URIs, which could allow content to execute in the top-level document&#39;s process instead of the intended frame, potentially enabling a sandbox escape. This vulnerability affects Firefox &lt; 138, Firefox ESR &lt; 128.10, Firefox ESR &lt; 115.23, Thunderbird &lt; 138, and Thunderbird &lt; 128.10.(CVE-2025-4083)Due to insufficient escaping of the special characters in the &#34;copy as cURL&#34; feature, an attacker could trick a user into using this command, potentially leading to local code execution on the user&#39;s system.*This bug only affects Firefox for Windows. Other versions of Firefox are unaffected.* This vulnerability affects Firefox ESR &lt; 128.10, Firefox ESR &lt; 115.23, and Thunderbird &lt; 128.10.(CVE-2025-4084)A vulnerability was identified in Thunderbird where XPath parsing could trigger undefined behavior due to missing null checks during attribute access. This could lead to out-of-bounds read access and potentially, memory corruption. This vulnerability affects Firefox &lt; 138, Firefox ESR &lt; 128.10, Thunderbird &lt; 138, and Thunderbird &lt; 128.10.(CVE-2025-4087)Memory safety bugs present in Firefox 137, Thunderbird 137, Firefox ESR 128.9, and Thunderbird 128.9. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 138, Firefox ESR &lt; 128.10, Thunderbird &lt; 138, and Thunderbird &lt; 128.10.(CVE-2025-4091)Memory safety bug present in Firefox ESR 128.9, and Thunderbird 128.9. This bug showed evidence of memory corruption and we presume that with enough effort this could have been exploited to run arbitrary code. This vulnerability affects Firefox ESR &lt; 128.10 and Thunderbird &lt; 128.10.(CVE-2025-4093)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="firefox" release="1.oe2203sp4" version="128.10.0">
                         <filename>firefox-128.10.0-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="firefox-debuginfo" release="1.oe2203sp4" version="128.10.0">
                         <filename>firefox-debuginfo-128.10.0-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="firefox-debugsource" release="1.oe2203sp4" version="128.10.0">
                         <filename>firefox-debugsource-128.10.0-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox" release="1.oe2203sp4" version="128.10.0">
                         <filename>firefox-128.10.0-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox-debuginfo" release="1.oe2203sp4" version="128.10.0">
                         <filename>firefox-debuginfo-128.10.0-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox-debugsource" release="1.oe2203sp4" version="128.10.0">
                         <filename>firefox-debugsource-128.10.0-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1492</id>
          <title>An update for erlang is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-05-09"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30211" id="CVE-2025-30211" title="CVE-2025-30211" type="cve"></reference>
          </references>
          <description>Erlang/OTP is a set of libraries for the Erlang programming language. Prior to versions OTP-27.3.1, 26.2.5.10, and 25.3.2.19, a maliciously formed KEX init message can result with high memory usage. Implementation does not verify RFC specified limits on algorithm names (64 characters) provided in KEX init message. Big KEX init packet may lead to inefficient processing of the error data. As a result, large amount of memory will be allocated for processing malicious data. Versions OTP-27.3.1, OTP-26.2.5.10, and OTP-25.3.2.19 fix the issue. Some workarounds are available. One may set option `parallel_login` to `false` and/or reduce the `max_sessions` option.(CVE-2025-30211)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="erlang" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-asn1" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-asn1-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-common_test" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-common_test-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-compiler" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-compiler-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-crypto" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-crypto-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-debugger" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-debugger-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-debuginfo" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-debuginfo-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-debugsource" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-debugsource-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-dialyzer" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-dialyzer-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-diameter" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-diameter-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-edoc" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-edoc-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-eldap" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-eldap-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-erl_docgen" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-erl_docgen-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-erl_interface" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-erl_interface-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-erts" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-erts-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-et" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-et-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-eunit" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-eunit-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-examples" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-examples-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-ftp" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-ftp-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-hipe" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-hipe-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-inets" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-inets-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-jinterface" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-jinterface-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-kernel" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-kernel-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-megaco" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-megaco-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-mnesia" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-mnesia-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-observer" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-observer-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-odbc" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-odbc-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-os_mon" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-os_mon-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-parsetools" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-parsetools-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-public_key" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-public_key-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-reltool" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-reltool-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-runtime_tools" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-runtime_tools-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-sasl" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-sasl-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-snmp" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-snmp-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-ssh" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-ssh-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-ssl" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-ssl-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-stdlib" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-stdlib-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-syntax_tools" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-syntax_tools-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-tftp" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-tftp-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-tools" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-tools-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-wx" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-wx-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-xmerl" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-xmerl-23.3.4.9-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-asn1" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-asn1-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-common_test" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-common_test-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-compiler" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-compiler-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-crypto" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-crypto-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-debugger" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-debugger-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-debuginfo" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-debuginfo-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-debugsource" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-debugsource-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-dialyzer" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-dialyzer-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-diameter" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-diameter-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-edoc" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-edoc-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-eldap" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-eldap-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-erl_docgen" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-erl_docgen-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-erl_interface" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-erl_interface-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-erts" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-erts-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-et" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-et-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-eunit" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-eunit-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-examples" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-examples-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-ftp" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-ftp-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-hipe" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-hipe-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-inets" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-inets-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-jinterface" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-jinterface-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-kernel" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-kernel-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-megaco" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-megaco-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-mnesia" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-mnesia-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-observer" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-observer-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-odbc" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-odbc-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-os_mon" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-os_mon-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-parsetools" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-parsetools-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-public_key" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-public_key-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-reltool" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-reltool-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-runtime_tools" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-runtime_tools-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-sasl" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-sasl-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-snmp" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-snmp-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-ssh" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-ssh-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-ssl" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-ssl-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-stdlib" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-stdlib-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-syntax_tools" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-syntax_tools-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-tftp" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-tftp-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-tools" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-tools-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-wx" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-wx-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-xmerl" release="6.oe2203sp4" version="23.3.4.9">
                         <filename>erlang-xmerl-23.3.4.9-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1495</id>
          <title>An update for haproxy is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-05-09"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-32464" id="CVE-2025-32464" title="CVE-2025-32464" type="cve"></reference>
          </references>
          <description>HAProxy 2.2 through 3.1.6, in certain uncommon configurations, has a sample_conv_regsub heap-based buffer overflow because of mishandling of the replacement of multiple short patterns with a longer one.(CVE-2025-32464)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="haproxy" release="16.oe2203sp4" version="2.6.6">
                         <filename>haproxy-2.6.6-16.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="haproxy-debuginfo" release="16.oe2203sp4" version="2.6.6">
                         <filename>haproxy-debuginfo-2.6.6-16.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="haproxy-debugsource" release="16.oe2203sp4" version="2.6.6">
                         <filename>haproxy-debugsource-2.6.6-16.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="haproxy-help" release="16.oe2203sp4" version="2.6.6">
                         <filename>haproxy-help-2.6.6-16.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="haproxy" release="16.oe2203sp4" version="2.6.6">
                         <filename>haproxy-2.6.6-16.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="haproxy-debuginfo" release="16.oe2203sp4" version="2.6.6">
                         <filename>haproxy-debuginfo-2.6.6-16.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="haproxy-debugsource" release="16.oe2203sp4" version="2.6.6">
                         <filename>haproxy-debugsource-2.6.6-16.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1501</id>
          <title>An update for ImageMagick is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2025-05-09"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-43965" id="CVE-2025-43965" title="CVE-2025-43965" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-46393" id="CVE-2025-46393" title="CVE-2025-46393" type="cve"></reference>
          </references>
          <description>In MIFF image processing in ImageMagick before 7.1.1-44, image depth is mishandled after SetQuantumFormat is used.(CVE-2025-43965)In multispectral MIFF image processing in ImageMagick before 7.1.1-44, packet_size is mishandled (related to the rendering of all channels in an arbitrary order).(CVE-2025-46393)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="ImageMagick" release="6.oe2203sp4" version="7.1.1.8">
                         <filename>ImageMagick-7.1.1.8-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-c++" release="6.oe2203sp4" version="7.1.1.8">
                         <filename>ImageMagick-c++-7.1.1.8-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-c++-devel" release="6.oe2203sp4" version="7.1.1.8">
                         <filename>ImageMagick-c++-devel-7.1.1.8-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-debuginfo" release="6.oe2203sp4" version="7.1.1.8">
                         <filename>ImageMagick-debuginfo-7.1.1.8-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-debugsource" release="6.oe2203sp4" version="7.1.1.8">
                         <filename>ImageMagick-debugsource-7.1.1.8-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-devel" release="6.oe2203sp4" version="7.1.1.8">
                         <filename>ImageMagick-devel-7.1.1.8-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-help" release="6.oe2203sp4" version="7.1.1.8">
                         <filename>ImageMagick-help-7.1.1.8-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-perl" release="6.oe2203sp4" version="7.1.1.8">
                         <filename>ImageMagick-perl-7.1.1.8-6.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick" release="6.oe2203sp4" version="7.1.1.8">
                         <filename>ImageMagick-7.1.1.8-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-c++" release="6.oe2203sp4" version="7.1.1.8">
                         <filename>ImageMagick-c++-7.1.1.8-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-c++-devel" release="6.oe2203sp4" version="7.1.1.8">
                         <filename>ImageMagick-c++-devel-7.1.1.8-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-debuginfo" release="6.oe2203sp4" version="7.1.1.8">
                         <filename>ImageMagick-debuginfo-7.1.1.8-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-debugsource" release="6.oe2203sp4" version="7.1.1.8">
                         <filename>ImageMagick-debugsource-7.1.1.8-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-devel" release="6.oe2203sp4" version="7.1.1.8">
                         <filename>ImageMagick-devel-7.1.1.8-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-help" release="6.oe2203sp4" version="7.1.1.8">
                         <filename>ImageMagick-help-7.1.1.8-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-perl" release="6.oe2203sp4" version="7.1.1.8">
                         <filename>ImageMagick-perl-7.1.1.8-6.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1503</id>
          <title>An update for edk2 is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-05-09"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38797" id="CVE-2024-38797" title="CVE-2024-38797" type="cve"></reference>
          </references>
          <description>EDK2 contains a vulnerability in the HashPeImageByType(). A user may cause a read out of bounds when a corrupted data pointer and length are sent via an adjecent network. A successful exploit of this vulnerability may lead to a loss of Integrity and/or Availability.(CVE-2024-38797)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="edk2-debuginfo" release="26.oe2203sp4" version="202011">
                         <filename>edk2-debuginfo-202011-26.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="edk2-debugsource" release="26.oe2203sp4" version="202011">
                         <filename>edk2-debugsource-202011-26.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="edk2-devel" release="26.oe2203sp4" version="202011">
                         <filename>edk2-devel-202011-26.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-aarch64" release="26.oe2203sp4" version="202011">
                         <filename>edk2-aarch64-202011-26.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-help" release="26.oe2203sp4" version="202011">
                         <filename>edk2-help-202011-26.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-ovmf" release="26.oe2203sp4" version="202011">
                         <filename>edk2-ovmf-202011-26.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-edk2-devel" release="26.oe2203sp4" version="202011">
                         <filename>python3-edk2-devel-202011-26.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-debuginfo" release="26.oe2203sp4" version="202011">
                         <filename>edk2-debuginfo-202011-26.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-debugsource" release="26.oe2203sp4" version="202011">
                         <filename>edk2-debugsource-202011-26.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-devel" release="26.oe2203sp4" version="202011">
                         <filename>edk2-devel-202011-26.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1506</id>
          <title>An update for GraphicsMagick is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-05-09"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-27795" id="CVE-2025-27795" title="CVE-2025-27795" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-32460" id="CVE-2025-32460" title="CVE-2025-32460" type="cve"></reference>
          </references>
          <description>ReadJXLImage in JXL in GraphicsMagick before 1.3.46 lacks image dimension resource limits.(CVE-2025-27795)GraphicsMagick before 8e56520 has a heap-based buffer over-read in ReadJXLImage in coders/jxl.c, related to an ImportViewPixelArea call.(CVE-2025-32460)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="GraphicsMagick" release="2.oe2203sp4" version="1.3.41">
                         <filename>GraphicsMagick-1.3.41-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="GraphicsMagick-c++" release="2.oe2203sp4" version="1.3.41">
                         <filename>GraphicsMagick-c++-1.3.41-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="GraphicsMagick-c++-devel" release="2.oe2203sp4" version="1.3.41">
                         <filename>GraphicsMagick-c++-devel-1.3.41-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="GraphicsMagick-debuginfo" release="2.oe2203sp4" version="1.3.41">
                         <filename>GraphicsMagick-debuginfo-1.3.41-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="GraphicsMagick-debugsource" release="2.oe2203sp4" version="1.3.41">
                         <filename>GraphicsMagick-debugsource-1.3.41-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="GraphicsMagick-devel" release="2.oe2203sp4" version="1.3.41">
                         <filename>GraphicsMagick-devel-1.3.41-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="GraphicsMagick-perl" release="2.oe2203sp4" version="1.3.41">
                         <filename>GraphicsMagick-perl-1.3.41-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="GraphicsMagick-help" release="2.oe2203sp4" version="1.3.41">
                         <filename>GraphicsMagick-help-1.3.41-2.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="GraphicsMagick" release="2.oe2203sp4" version="1.3.41">
                         <filename>GraphicsMagick-1.3.41-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="GraphicsMagick-c++" release="2.oe2203sp4" version="1.3.41">
                         <filename>GraphicsMagick-c++-1.3.41-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="GraphicsMagick-c++-devel" release="2.oe2203sp4" version="1.3.41">
                         <filename>GraphicsMagick-c++-devel-1.3.41-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="GraphicsMagick-debuginfo" release="2.oe2203sp4" version="1.3.41">
                         <filename>GraphicsMagick-debuginfo-1.3.41-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="GraphicsMagick-debugsource" release="2.oe2203sp4" version="1.3.41">
                         <filename>GraphicsMagick-debugsource-1.3.41-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="GraphicsMagick-devel" release="2.oe2203sp4" version="1.3.41">
                         <filename>GraphicsMagick-devel-1.3.41-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="GraphicsMagick-perl" release="2.oe2203sp4" version="1.3.41">
                         <filename>GraphicsMagick-perl-1.3.41-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1507</id>
          <title>An update for activemq is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-05-16"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-27533" id="CVE-2025-27533" title="CVE-2025-27533" type="cve"></reference>
          </references>
          <description>Memory Allocation with Excessive Size Value vulnerability in Apache ActiveMQ.During unmarshalling of OpenWire commands the size value of buffers was not properly validated which could lead to excessive memory allocation and be exploited to cause a denial of service (DoS) by depleting process memory, thereby affecting applications and services that rely on the availability of the ActiveMQ broker when not using mutual TLS connections.This issue affects Apache ActiveMQ: from 6.0.0 before 6.1.6, from 5.18.0 before 5.18.7, from 5.17.0 before 5.17.7, before 5.16.8. ActiveMQ 5.19.0 is not affected.Users are recommended to upgrade to version 6.1.6+, 5.19.0+,  5.18.7+, 5.17.7, or 5.16.8 or which fixes the issue.Existing users may implement mutual TLS to mitigate the risk on affected brokers.(CVE-2025-27533)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="activemq" release="1.oe2203sp4" version="5.16.8">
                         <filename>activemq-5.16.8-1.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="activemq-javadoc" release="1.oe2203sp4" version="5.16.8">
                         <filename>activemq-javadoc-5.16.8-1.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1515</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-05-16"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49901" id="CVE-2022-49901" title="CVE-2022-49901" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53093" id="CVE-2023-53093" title="CVE-2023-53093" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21999" id="CVE-2025-21999" title="CVE-2025-21999" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-23144" id="CVE-2025-23144" title="CVE-2025-23144" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:blk-mq: Fix kmemleak in blk_mq_init_allocated_queueThere is a kmemleak caused by modprobe null_blk.kounreferenced object 0xffff8881acb1f000 (size 1024):  comm &#34;modprobe&#34;, pid 836, jiffies 4294971190 (age 27.068s)  hex dump (first 32 bytes):    00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00  .....N..........    ff ff ff ff ff ff ff ff 00 53 99 9e ff ff ff ff  .........S......  backtrace:    [&lt;000000004a10c249&gt;] kmalloc_node_trace+0x22/0x60    [&lt;00000000648f7950&gt;] blk_mq_alloc_and_init_hctx+0x289/0x350    [&lt;00000000af06de0e&gt;] blk_mq_realloc_hw_ctxs+0x2fe/0x3d0    [&lt;00000000e00c1872&gt;] blk_mq_init_allocated_queue+0x48c/0x1440    [&lt;00000000d16b4e68&gt;] __blk_mq_alloc_disk+0xc8/0x1c0    [&lt;00000000d10c98c3&gt;] 0xffffffffc450d69d    [&lt;00000000b9299f48&gt;] 0xffffffffc4538392    [&lt;0000000061c39ed6&gt;] do_one_initcall+0xd0/0x4f0    [&lt;00000000b389383b&gt;] do_init_module+0x1a4/0x680    [&lt;0000000087cf3542&gt;] load_module+0x6249/0x7110    [&lt;00000000beba61b8&gt;] __do_sys_finit_module+0x140/0x200    [&lt;00000000fdcfff51&gt;] do_syscall_64+0x35/0x80    [&lt;000000003c0f1f71&gt;] entry_SYSCALL_64_after_hwframe+0x46/0xb0That is because q-&gt;ma_ops is set to NULL before blk_release_queue iscalled.blk_mq_init_queue_data  blk_mq_init_allocated_queue    blk_mq_realloc_hw_ctxs      for (i = 0; i &lt; set-&gt;nr_hw_queues; i++) {        old_hctx = xa_load(&amp;q-&gt;hctx_table, i);        if (!blk_mq_alloc_and_init_hctx(.., i, ..))&#x9;&#x9;[1]          if (!old_hctx)&#x9;    break;      xa_for_each_start(&amp;q-&gt;hctx_table, j, hctx, j)        blk_mq_exit_hctx(q, set, hctx, j); &#x9;&#x9;&#x9;[2]    if (!q-&gt;nr_hw_queues)&#x9;&#x9;&#x9;&#x9;&#x9;[3]      goto err_hctxs;  err_exit:      q-&gt;mq_ops = NULL;&#x9;&#x9;&#x9;  &#x9;&#x9;&#x9;[4]  blk_put_queue    blk_release_queue      if (queue_is_mq(q))&#x9;&#x9;&#x9;&#x9;&#x9;[5]        blk_mq_release(q);[1]: blk_mq_alloc_and_init_hctx failed at i != 0.[2]: The hctxs allocated by [1] are moved to q-&gt;unused_hctx_list andwill be cleaned up in blk_mq_release.[3]: q-&gt;nr_hw_queues is 0.[4]: Set q-&gt;mq_ops to NULL.[5]: queue_is_mq returns false due to [4]. And blk_mq_releasewill not be called. The hctxs in q-&gt;unused_hctx_list are leaked.To fix it, call blk_release_queue in exception path.(CVE-2022-49901)In the Linux kernel, the following vulnerability has been resolved:tracing: Do not let histogram values have some modifiersHistogram values can not be strings, stacktraces, graphs, symbols,syscalls, or grouped in buckets or log. Give an error if a value is set todo so.Note, the histogram code was not prepared to handle these modifiers forhistograms and caused a bug.Mark Rutland reported: # echo &#39;p:copy_to_user __arch_copy_to_user n=$arg2&#39; &gt;&gt; /sys/kernel/tracing/kprobe_events # echo &#39;hist:keys=n:vals=hitcount.buckets=8:sort=hitcount&#39; &gt; /sys/kernel/tracing/events/kprobes/copy_to_user/trigger # cat /sys/kernel/tracing/events/kprobes/copy_to_user/hist[  143.694628] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000[  143.695190] Mem abort info:[  143.695362]   ESR = 0x0000000096000004[  143.695604]   EC = 0x25: DABT (current EL), IL = 32 bits[  143.695889]   SET = 0, FnV = 0[  143.696077]   EA = 0, S1PTW = 0[  143.696302]   FSC = 0x04: level 0 translation fault[  143.702381] Data abort info:[  143.702614]   ISV = 0, ISS = 0x00000004[  143.702832]   CM = 0, WnR = 0[  143.703087] user pgtable: 4k pages, 48-bit VAs, pgdp=00000000448f9000[  143.703407] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000[  143.704137] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP[  143.704714] Modules linked in:[  143.705273] CPU: 0 PID: 133 Comm: cat Not tainted 6.2.0-00003-g6fc512c10a7c #3[  143.706138] Hardware name: linux,dummy-virt (DT)[  143.706723] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[  143.707120] pc : hist_field_name.part.0+0x14/0x140[  143.707504] lr : hist_field_name.part.0+0x104/0x140[  143.707774] sp : ffff800008333a30[  143.707952] x29: ffff800008333a30 x28: 0000000000000001 x27: 0000000000400cc0[  143.708429] x26: ffffd7a653b20260 x25: 0000000000000000 x24: ffff10d303ee5800[  143.708776] x23: ffffd7a6539b27b0 x22: ffff10d303fb8c00 x21: 0000000000000001[  143.709127] x20: ffff10d303ec2000 x19: 0000000000000000 x18: 0000000000000000[  143.709478] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000[  143.709824] x14: 0000000000000000 x13: 203a6f666e692072 x12: 6567676972742023[  143.710179] x11: 0a230a6d6172676f x10: 000000000000002c x9 : ffffd7a6521e018c[  143.710584] x8 : 000000000000002c x7 : 7f7f7f7f7f7f7f7f x6 : 000000000000002c[  143.710915] x5 : ffff10d303b0103e x4 : ffffd7a653b20261 x3 : 000000000000003d[  143.711239] x2 : 0000000000020001 x1 : 0000000000000001 x0 : 0000000000000000[  143.711746] Call trace:[  143.712115]  hist_field_name.part.0+0x14/0x140[  143.712642]  hist_field_name.part.0+0x104/0x140[  143.712925]  hist_field_print+0x28/0x140[  143.713125]  event_hist_trigger_print+0x174/0x4d0[  143.713348]  hist_show+0xf8/0x980[  143.713521]  seq_read_iter+0x1bc/0x4b0[  143.713711]  seq_read+0x8c/0xc4[  143.713876]  vfs_read+0xc8/0x2a4[  143.714043]  ksys_read+0x70/0xfc[  143.714218]  __arm64_sys_read+0x24/0x30[  143.714400]  invoke_syscall+0x50/0x120[  143.714587]  el0_svc_common.constprop.0+0x4c/0x100[  143.714807]  do_el0_svc+0x44/0xd0[  143.714970]  el0_svc+0x2c/0x84[  143.715134]  el0t_64_sync_handler+0xbc/0x140[  143.715334]  el0t_64_sync+0x190/0x194[  143.715742] Code: a9bd7bfd 910003fd a90153f3 aa0003f3 (f9400000)[  143.716510] ---[ end trace 0000000000000000 ]---Segmentation fault(CVE-2023-53093)In the Linux kernel, the following vulnerability has been resolved:proc: fix UAF in proc_get_inode()Fix race between rmmod and /proc/XXX&#39;s inode instantiation.The bug is that pde-&gt;proc_ops don&#39;t belong to /proc, it belongs to amodule, therefore dereferencing it after /proc entry has been registeredis a bug unless use_pde/unuse_pde() pair has been used.use_pde/unuse_pde can be avoided (2 atomic ops!) because pde-&gt;proc_opsnever changes so information necessary for inode instantiation can besaved _before_ proc_register() in PDE itself and used later, avoidingpde-&gt;proc_ops-&gt;...  dereference.      rmmod                         lookupsys_delete_module                         proc_lookup_de&#x9;&#x9;&#x9;   pde_get(de);&#x9;&#x9;&#x9;   proc_get_inode(dir-&gt;i_sb, de);  mod-&gt;exit()    proc_remove      remove_proc_subtree       proc_entry_rundown(de);  free_module(mod);                               if (S_ISREG(inode-&gt;i_mode))&#x9;                         if (de-&gt;proc_ops-&gt;proc_read_iter)                           --&gt; As module is already freed, will trigger UAFBUG: unable to handle page fault for address: fffffbfff80a702bPGD 817fc4067 P4D 817fc4067 PUD 817fc0067 PMD 102ef4067 PTE 0Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTICPU: 26 UID: 0 PID: 2667 Comm: ls Tainted: GHardware name: QEMU Standard PC (i440FX + PIIX, 1996)RIP: 0010:proc_get_inode+0x302/0x6e0RSP: 0018:ffff88811c837998 EFLAGS: 00010a06RAX: dffffc0000000000 RBX: ffffffffc0538140 RCX: 0000000000000007RDX: 1ffffffff80a702b RSI: 0000000000000001 RDI: ffffffffc0538158RBP: ffff8881299a6000 R08: 0000000067bbe1e5 R09: 1ffff11023906f20R10: ffffffffb560ca07 R11: ffffffffb2b43a58 R12: ffff888105bb78f0R13: ffff888100518048 R14: ffff8881299a6004 R15: 0000000000000001FS:  00007f95b9686840(0000) GS:ffff8883af100000(0000) knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: fffffbfff80a702b CR3: 0000000117dd2000 CR4: 00000000000006f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: &lt;TASK&gt; proc_lookup_de+0x11f/0x2e0 __lookup_slow+0x188/0x350 walk_component+0x2ab/0x4f0 path_lookupat+0x120/0x660 filename_lookup+0x1ce/0x560 vfs_statx+0xac/0x150 __do_sys_newstat+0x96/0x110 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e[adobriyan@gmail.com: don&#39;t do 2 atomic ops on the common path](CVE-2025-21999)In the Linux kernel, the following vulnerability has been resolved:backlight: led_bl: Hold led_access lock when calling led_sysfs_disable()Lockdep detects the following issue on led-backlight removal:  [  142.315935] ------------[ cut here ]------------  [  142.315954] WARNING: CPU: 2 PID: 292 at drivers/leds/led-core.c:455 led_sysfs_enable+0x54/0x80  ...  [  142.500725] Call trace:  [  142.503176]  led_sysfs_enable+0x54/0x80 (P)  [  142.507370]  led_bl_remove+0x80/0xa8 [led_bl]  [  142.511742]  platform_remove+0x30/0x58  [  142.515501]  device_remove+0x54/0x90  ...Indeed, led_sysfs_enable() has to be called with the led_accesslock held.Hold the lock when calling led_sysfs_disable().(CVE-2025-23144)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="bpftool" release="263.0.0.166.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-263.0.0.166.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="263.0.0.166.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-263.0.0.166.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="263.0.0.166.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-263.0.0.166.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="263.0.0.166.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-263.0.0.166.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="263.0.0.166.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-263.0.0.166.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="263.0.0.166.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-263.0.0.166.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="263.0.0.166.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-263.0.0.166.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="263.0.0.166.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-263.0.0.166.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="263.0.0.166.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-263.0.0.166.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="263.0.0.166.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-263.0.0.166.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="263.0.0.166.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-263.0.0.166.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="263.0.0.166.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-263.0.0.166.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="263.0.0.166.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-263.0.0.166.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="263.0.0.166.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-263.0.0.166.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="263.0.0.166.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-263.0.0.166.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="263.0.0.166.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-263.0.0.166.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="263.0.0.166.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-263.0.0.166.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="263.0.0.166.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-263.0.0.166.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="263.0.0.166.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-263.0.0.166.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="263.0.0.166.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-263.0.0.166.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="263.0.0.166.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-263.0.0.166.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="263.0.0.166.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-263.0.0.166.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="263.0.0.166.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-263.0.0.166.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="263.0.0.166.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-263.0.0.166.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="263.0.0.166.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-263.0.0.166.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="263.0.0.166.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-263.0.0.166.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="263.0.0.166.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-263.0.0.166.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="263.0.0.166.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-263.0.0.166.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="263.0.0.166.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-263.0.0.166.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="263.0.0.166.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-263.0.0.166.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1516</id>
          <title>An update for mariadb is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-05-16"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52969" id="CVE-2023-52969" title="CVE-2023-52969" type="cve"></reference>
          </references>
          <description>MariaDB Server 10.4 through 10.5.*, 10.6 through 10.6.*, 10.7 through 10.11.*, and 11.0 through 11.0.* can sometimes crash with an empty backtrace log. This may be related to make_aggr_tables_info and optimize_stage2.(CVE-2023-52969)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="mariadb" release="1.oe2203sp4" version="10.5.29">
                         <filename>mariadb-10.5.29-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-backup" release="1.oe2203sp4" version="10.5.29">
                         <filename>mariadb-backup-10.5.29-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-common" release="1.oe2203sp4" version="10.5.29">
                         <filename>mariadb-common-10.5.29-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-config" release="1.oe2203sp4" version="10.5.29">
                         <filename>mariadb-config-10.5.29-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-debuginfo" release="1.oe2203sp4" version="10.5.29">
                         <filename>mariadb-debuginfo-10.5.29-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-debugsource" release="1.oe2203sp4" version="10.5.29">
                         <filename>mariadb-debugsource-10.5.29-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-devel" release="1.oe2203sp4" version="10.5.29">
                         <filename>mariadb-devel-10.5.29-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-embedded" release="1.oe2203sp4" version="10.5.29">
                         <filename>mariadb-embedded-10.5.29-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-embedded-devel" release="1.oe2203sp4" version="10.5.29">
                         <filename>mariadb-embedded-devel-10.5.29-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-errmsg" release="1.oe2203sp4" version="10.5.29">
                         <filename>mariadb-errmsg-10.5.29-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-gssapi-server" release="1.oe2203sp4" version="10.5.29">
                         <filename>mariadb-gssapi-server-10.5.29-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-oqgraph-engine" release="1.oe2203sp4" version="10.5.29">
                         <filename>mariadb-oqgraph-engine-10.5.29-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-pam" release="1.oe2203sp4" version="10.5.29">
                         <filename>mariadb-pam-10.5.29-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-rocksdb-engine" release="1.oe2203sp4" version="10.5.29">
                         <filename>mariadb-rocksdb-engine-10.5.29-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-server" release="1.oe2203sp4" version="10.5.29">
                         <filename>mariadb-server-10.5.29-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-server-galera" release="1.oe2203sp4" version="10.5.29">
                         <filename>mariadb-server-galera-10.5.29-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-server-utils" release="1.oe2203sp4" version="10.5.29">
                         <filename>mariadb-server-utils-10.5.29-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-test" release="1.oe2203sp4" version="10.5.29">
                         <filename>mariadb-test-10.5.29-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb" release="1.oe2203sp4" version="10.5.29">
                         <filename>mariadb-10.5.29-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-backup" release="1.oe2203sp4" version="10.5.29">
                         <filename>mariadb-backup-10.5.29-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-common" release="1.oe2203sp4" version="10.5.29">
                         <filename>mariadb-common-10.5.29-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-config" release="1.oe2203sp4" version="10.5.29">
                         <filename>mariadb-config-10.5.29-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-debuginfo" release="1.oe2203sp4" version="10.5.29">
                         <filename>mariadb-debuginfo-10.5.29-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-debugsource" release="1.oe2203sp4" version="10.5.29">
                         <filename>mariadb-debugsource-10.5.29-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-devel" release="1.oe2203sp4" version="10.5.29">
                         <filename>mariadb-devel-10.5.29-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-embedded" release="1.oe2203sp4" version="10.5.29">
                         <filename>mariadb-embedded-10.5.29-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-embedded-devel" release="1.oe2203sp4" version="10.5.29">
                         <filename>mariadb-embedded-devel-10.5.29-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-errmsg" release="1.oe2203sp4" version="10.5.29">
                         <filename>mariadb-errmsg-10.5.29-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-gssapi-server" release="1.oe2203sp4" version="10.5.29">
                         <filename>mariadb-gssapi-server-10.5.29-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-oqgraph-engine" release="1.oe2203sp4" version="10.5.29">
                         <filename>mariadb-oqgraph-engine-10.5.29-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-pam" release="1.oe2203sp4" version="10.5.29">
                         <filename>mariadb-pam-10.5.29-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-server" release="1.oe2203sp4" version="10.5.29">
                         <filename>mariadb-server-10.5.29-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-server-galera" release="1.oe2203sp4" version="10.5.29">
                         <filename>mariadb-server-galera-10.5.29-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-server-utils" release="1.oe2203sp4" version="10.5.29">
                         <filename>mariadb-server-utils-10.5.29-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-test" release="1.oe2203sp4" version="10.5.29">
                         <filename>mariadb-test-10.5.29-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1522</id>
          <title>An update for gnupg2 is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2025-05-16"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-30258" id="CVE-2025-30258" title="CVE-2025-30258" type="cve"></reference>
          </references>
          <description>In GnuPG before 2.5.5, if a user chooses to import a certificate with certain crafted subkey data that lacks a valid backsig or that has incorrect usage flags, the user loses the ability to verify signatures made from certain other signing keys, aka a &#34;verification DoS.&#34;(CVE-2025-30258)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="gnupg2" release="7.oe2203sp4" version="2.2.32">
                         <filename>gnupg2-2.2.32-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gnupg2-debuginfo" release="7.oe2203sp4" version="2.2.32">
                         <filename>gnupg2-debuginfo-2.2.32-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gnupg2-debugsource" release="7.oe2203sp4" version="2.2.32">
                         <filename>gnupg2-debugsource-2.2.32-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="gnupg2-help" release="7.oe2203sp4" version="2.2.32">
                         <filename>gnupg2-help-2.2.32-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gnupg2" release="7.oe2203sp4" version="2.2.32">
                         <filename>gnupg2-2.2.32-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gnupg2-debuginfo" release="7.oe2203sp4" version="2.2.32">
                         <filename>gnupg2-debuginfo-2.2.32-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gnupg2-debugsource" release="7.oe2203sp4" version="2.2.32">
                         <filename>gnupg2-debugsource-2.2.32-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1524</id>
          <title>An update for python-django is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-05-16"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-32873" id="CVE-2025-32873" title="CVE-2025-32873" type="cve"></reference>
          </references>
          <description>An issue was discovered in Django 4.2 before 4.2.21, 5.1 before 5.1.9, and 5.2 before 5.2.1. The django.utils.html.strip_tags() function is vulnerable to a potential denial-of-service (slow performance) when processing inputs containing large sequences of incomplete HTML tags. The template filter striptags is also vulnerable, because it is built on top of strip_tags().(CVE-2025-32873)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="python-django-help" release="6.oe2203sp4" version="4.2.15">
                         <filename>python-django-help-4.2.15-6.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-Django" release="6.oe2203sp4" version="4.2.15">
                         <filename>python3-Django-4.2.15-6.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1525</id>
          <title>An update for glib2 is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2025-05-16"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-3360" id="CVE-2025-3360" title="CVE-2025-3360" type="cve"></reference>
          </references>
          <description>A flaw was found in GLib. An integer overflow and buffer under-read occur when parsing a long invalid ISO 8601 timestamp with the g_date_time_new_from_iso8601() function.(CVE-2025-3360)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="glib2" release="21.oe2203sp4" version="2.72.2">
                         <filename>glib2-2.72.2-21.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glib2-debuginfo" release="21.oe2203sp4" version="2.72.2">
                         <filename>glib2-debuginfo-2.72.2-21.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glib2-debugsource" release="21.oe2203sp4" version="2.72.2">
                         <filename>glib2-debugsource-2.72.2-21.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glib2-devel" release="21.oe2203sp4" version="2.72.2">
                         <filename>glib2-devel-2.72.2-21.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glib2-static" release="21.oe2203sp4" version="2.72.2">
                         <filename>glib2-static-2.72.2-21.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glib2-tests" release="21.oe2203sp4" version="2.72.2">
                         <filename>glib2-tests-2.72.2-21.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="glib2-help" release="21.oe2203sp4" version="2.72.2">
                         <filename>glib2-help-2.72.2-21.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glib2" release="21.oe2203sp4" version="2.72.2">
                         <filename>glib2-2.72.2-21.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glib2-debuginfo" release="21.oe2203sp4" version="2.72.2">
                         <filename>glib2-debuginfo-2.72.2-21.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glib2-debugsource" release="21.oe2203sp4" version="2.72.2">
                         <filename>glib2-debugsource-2.72.2-21.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glib2-devel" release="21.oe2203sp4" version="2.72.2">
                         <filename>glib2-devel-2.72.2-21.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glib2-static" release="21.oe2203sp4" version="2.72.2">
                         <filename>glib2-static-2.72.2-21.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glib2-tests" release="21.oe2203sp4" version="2.72.2">
                         <filename>glib2-tests-2.72.2-21.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1526</id>
          <title>An update for yasm is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-05-16"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33454" id="CVE-2021-33454" title="CVE-2021-33454" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33464" id="CVE-2021-33464" title="CVE-2021-33464" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29579" id="CVE-2023-29579" title="CVE-2023-29579" type="cve"></reference>
          </references>
          <description>An issue was discovered in yasm version 1.3.0. There is a NULL pointer dereference in yasm_expr_get_intnum() in libyasm/expr.c.(CVE-2021-33454)An issue was discovered in yasm version 1.3.0. There is a heap-buffer-overflow in inc_fopen() in modules/preprocs/nasm/nasm-pp.c.(CVE-2021-33464)yasm 1.3.0.55.g101bc was discovered to contain a stack overflow via the component yasm/yasm+0x43b466 in vsprintf. Note: This has been disputed by third parties who argue this is a bug and not a security issue because yasm is a standalone program not designed to run untrusted code.(CVE-2023-29579)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="yasm" release="13.oe2203sp4" version="1.3.0">
                         <filename>yasm-1.3.0-13.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="yasm-debuginfo" release="13.oe2203sp4" version="1.3.0">
                         <filename>yasm-debuginfo-1.3.0-13.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="yasm-debugsource" release="13.oe2203sp4" version="1.3.0">
                         <filename>yasm-debugsource-1.3.0-13.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="yasm-devel" release="13.oe2203sp4" version="1.3.0">
                         <filename>yasm-devel-1.3.0-13.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="yasm-help" release="13.oe2203sp4" version="1.3.0">
                         <filename>yasm-help-1.3.0-13.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="yasm" release="13.oe2203sp4" version="1.3.0">
                         <filename>yasm-1.3.0-13.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="yasm-debuginfo" release="13.oe2203sp4" version="1.3.0">
                         <filename>yasm-debuginfo-1.3.0-13.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="yasm-debugsource" release="13.oe2203sp4" version="1.3.0">
                         <filename>yasm-debugsource-1.3.0-13.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="yasm-devel" release="13.oe2203sp4" version="1.3.0">
                         <filename>yasm-devel-1.3.0-13.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1528</id>
          <title>An update for microcode_ctl is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-05-16"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-28956" id="CVE-2024-28956" title="CVE-2024-28956" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43420" id="CVE-2024-43420" title="CVE-2024-43420" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45332" id="CVE-2024-45332" title="CVE-2024-45332" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-20012" id="CVE-2025-20012" title="CVE-2025-20012" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-20054" id="CVE-2025-20054" title="CVE-2025-20054" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-20103" id="CVE-2025-20103" title="CVE-2025-20103" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-20623" id="CVE-2025-20623" title="CVE-2025-20623" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-24495" id="CVE-2025-24495" title="CVE-2025-24495" type="cve"></reference>
          </references>
          <description>Exposure of Sensitive Information in Shared Microarchitectural Structures during Transient Execution for some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via local access.(CVE-2024-28956)Exposure of sensitive information caused by shared microarchitectural predictor state that influences transient execution for some Intel Atom(R) processors may allow an authenticated user to potentially enable information disclosure via local access.(CVE-2024-43420)Exposure of sensitive information caused by shared microarchitectural predictor state that influences transient execution in the indirect branch predictors for some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via local access.(CVE-2024-45332)Incorrect behavior order for some Intel(R) Core™ Ultra Processors may allow an unauthenticated user to potentially enable information disclosure via physical access.(CVE-2025-20012)Uncaught exception in the core management mechanism for some Intel(R) Processors may allow an authenticated user to potentially enable denial of service via local access.(CVE-2025-20054)Insufficient resource pool in the core management mechanism for some Intel(R) Processors may allow an authenticated user to potentially enable denial of service via local access.(CVE-2025-20103)Exposure of sensitive information caused by shared microarchitectural predictor state that influences transient execution for some Intel(R) Core™ processors (10th Generation) may allow an authenticated user to potentially enable information disclosure via local access.(CVE-2025-20623)Incorrect initialization of resource in the branch prediction unit for some Intel(R) Core™ Ultra Processors may allow an authenticated user to potentially enable information disclosure via local access.(CVE-2025-24495)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="x86_64" name="microcode_ctl" release="1.oe2203sp4" version="20250512">
                         <filename>microcode_ctl-20250512-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1530</id>
          <title>An update for python-jinja2 is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-05-16"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-27516" id="CVE-2025-27516" title="CVE-2025-27516" type="cve"></reference>
          </references>
          <description>Jinja is an extensible templating engine. Prior to 3.1.6, an oversight in how the Jinja sandboxed environment interacts with the |attr filter allows an attacker that controls the content of a template to execute arbitrary Python code. To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates. Jinja&#39;s sandbox does catch calls to str.format and ensures they don&#39;t escape the sandbox. However, it&#39;s possible to use the |attr filter to get a reference to a string&#39;s plain format method, bypassing the sandbox. After the fix, the |attr filter no longer bypasses the environment&#39;s attribute lookup. This vulnerability is fixed in 3.1.6.(CVE-2025-27516)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="python-jinja2-help" release="7.oe2203sp4" version="3.0.3">
                         <filename>python-jinja2-help-3.0.3-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-jinja2" release="7.oe2203sp4" version="3.0.3">
                         <filename>python3-jinja2-3.0.3-7.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1537</id>
          <title>An update for libxml2 is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-05-23"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-32414" id="CVE-2025-32414" title="CVE-2025-32414" type="cve"></reference>
          </references>
          <description>In libxml2 before 2.13.8 and 2.14.x before 2.14.2, out-of-bounds memory access can occur in the Python API (Python bindings) because of an incorrect return value. This occurs in xmlPythonFileRead and xmlPythonFileReadRaw because of a difference between bytes and characters.(CVE-2025-32414)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libxml2" release="17.oe2203sp4" version="2.9.14">
                         <filename>libxml2-2.9.14-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libxml2-debuginfo" release="17.oe2203sp4" version="2.9.14">
                         <filename>libxml2-debuginfo-2.9.14-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libxml2-debugsource" release="17.oe2203sp4" version="2.9.14">
                         <filename>libxml2-debugsource-2.9.14-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libxml2-devel" release="17.oe2203sp4" version="2.9.14">
                         <filename>libxml2-devel-2.9.14-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-libxml2" release="17.oe2203sp4" version="2.9.14">
                         <filename>python3-libxml2-2.9.14-17.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="libxml2-help" release="17.oe2203sp4" version="2.9.14">
                         <filename>libxml2-help-2.9.14-17.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libxml2" release="17.oe2203sp4" version="2.9.14">
                         <filename>libxml2-2.9.14-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libxml2-debuginfo" release="17.oe2203sp4" version="2.9.14">
                         <filename>libxml2-debuginfo-2.9.14-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libxml2-debugsource" release="17.oe2203sp4" version="2.9.14">
                         <filename>libxml2-debugsource-2.9.14-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libxml2-devel" release="17.oe2203sp4" version="2.9.14">
                         <filename>libxml2-devel-2.9.14-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-libxml2" release="17.oe2203sp4" version="2.9.14">
                         <filename>python3-libxml2-2.9.14-17.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1543</id>
          <title>An update for yelp-xsl is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-05-23"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-3155" id="CVE-2025-3155" title="CVE-2025-3155" type="cve"></reference>
          </references>
          <description>A flaw was found in Yelp. The Gnome user help application allows the help document to execute arbitrary scripts. This vulnerability allows malicious users to input help documents, which may exfiltrate user files to an external environment.(CVE-2025-3155)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="yelp-xsl" release="2.oe2203sp4" version="3.38.3">
                         <filename>yelp-xsl-3.38.3-2.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="yelp-xsl-devel" release="2.oe2203sp4" version="3.38.3">
                         <filename>yelp-xsl-devel-3.38.3-2.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="yelp-xsl-help" release="2.oe2203sp4" version="3.38.3">
                         <filename>yelp-xsl-help-3.38.3-2.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1544</id>
          <title>An update for perl-FCGI is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-05-23"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40907" id="CVE-2025-40907" title="CVE-2025-40907" type="cve"></reference>
          </references>
          <description>FCGI versions 0.44 through 0.82, for Perl, include a vulnerable version of the FastCGI fcgi2 (aka fcgi) library.The included FastCGI library is affected by  CVE-2025-23016, causing an integer overflow (and resultant heap-based buffer overflow) via crafted nameLen or valueLen values in data to the IPC socket. This occurs in ReadParams in fcgiapp.c.(CVE-2025-40907)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="perl-FCGI" release="14.oe2203sp4" version="0.78">
                         <filename>perl-FCGI-0.78-14.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="perl-FCGI-debuginfo" release="14.oe2203sp4" version="0.78">
                         <filename>perl-FCGI-debuginfo-0.78-14.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="perl-FCGI-debugsource" release="14.oe2203sp4" version="0.78">
                         <filename>perl-FCGI-debugsource-0.78-14.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="perl-FCGI-help" release="14.oe2203sp4" version="0.78">
                         <filename>perl-FCGI-help-0.78-14.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="perl-FCGI" release="14.oe2203sp4" version="0.78">
                         <filename>perl-FCGI-0.78-14.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="perl-FCGI-debuginfo" release="14.oe2203sp4" version="0.78">
                         <filename>perl-FCGI-debuginfo-0.78-14.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="perl-FCGI-debugsource" release="14.oe2203sp4" version="0.78">
                         <filename>perl-FCGI-debugsource-0.78-14.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="perl-FCGI-help" release="14.oe2203sp4" version="0.78">
                         <filename>perl-FCGI-help-0.78-14.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1546</id>
          <title>An update for firefox is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-05-23"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-4918" id="CVE-2025-4918" title="CVE-2025-4918" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-4919" id="CVE-2025-4919" title="CVE-2025-4919" type="cve"></reference>
          </references>
          <description>An attacker was able to perform an out-of-bounds read or write on a JavaScript `Promise` object. This vulnerability affects Firefox &lt; 138.0.4, Firefox ESR &lt; 128.10.1, Firefox ESR &lt; 115.23.1, Thunderbird &lt; 128.10.2, and Thunderbird &lt; 138.0.2.(CVE-2025-4918)An attacker was able to perform an out-of-bounds read or write on a JavaScript object by confusing array index sizes. This vulnerability affects Firefox &lt; 138.0.4, Firefox ESR &lt; 128.10.1, Firefox ESR &lt; 115.23.1, Thunderbird &lt; 128.10.2, and Thunderbird &lt; 138.0.2.(CVE-2025-4919)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="firefox" release="1.oe2203sp4" version="128.10.1">
                         <filename>firefox-128.10.1-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="firefox-debuginfo" release="1.oe2203sp4" version="128.10.1">
                         <filename>firefox-debuginfo-128.10.1-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="firefox-debugsource" release="1.oe2203sp4" version="128.10.1">
                         <filename>firefox-debugsource-128.10.1-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox" release="1.oe2203sp4" version="128.10.1">
                         <filename>firefox-128.10.1-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox-debuginfo" release="1.oe2203sp4" version="128.10.1">
                         <filename>firefox-debuginfo-128.10.1-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox-debugsource" release="1.oe2203sp4" version="128.10.1">
                         <filename>firefox-debugsource-128.10.1-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1550</id>
          <title>An update for openssh is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-05-23"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-32728" id="CVE-2025-32728" title="CVE-2025-32728" type="cve"></reference>
          </references>
          <description>In sshd in OpenSSH before 10.0, the DisableForwarding directive does not adhere to the documentation stating that it disables X11 and agent forwarding.(CVE-2025-32728)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="openssh" release="35.oe2203sp4" version="8.8p1">
                         <filename>openssh-8.8p1-35.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-askpass" release="35.oe2203sp4" version="8.8p1">
                         <filename>openssh-askpass-8.8p1-35.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-clients" release="35.oe2203sp4" version="8.8p1">
                         <filename>openssh-clients-8.8p1-35.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-debuginfo" release="35.oe2203sp4" version="8.8p1">
                         <filename>openssh-debuginfo-8.8p1-35.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-debugsource" release="35.oe2203sp4" version="8.8p1">
                         <filename>openssh-debugsource-8.8p1-35.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-keycat" release="35.oe2203sp4" version="8.8p1">
                         <filename>openssh-keycat-8.8p1-35.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-server" release="35.oe2203sp4" version="8.8p1">
                         <filename>openssh-server-8.8p1-35.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pam_ssh_agent_auth" release="4.35.oe2203sp4" version="0.10.4">
                         <filename>pam_ssh_agent_auth-0.10.4-4.35.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="openssh-help" release="35.oe2203sp4" version="8.8p1">
                         <filename>openssh-help-8.8p1-35.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh" release="35.oe2203sp4" version="8.8p1">
                         <filename>openssh-8.8p1-35.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-askpass" release="35.oe2203sp4" version="8.8p1">
                         <filename>openssh-askpass-8.8p1-35.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-clients" release="35.oe2203sp4" version="8.8p1">
                         <filename>openssh-clients-8.8p1-35.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-debuginfo" release="35.oe2203sp4" version="8.8p1">
                         <filename>openssh-debuginfo-8.8p1-35.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-debugsource" release="35.oe2203sp4" version="8.8p1">
                         <filename>openssh-debugsource-8.8p1-35.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-keycat" release="35.oe2203sp4" version="8.8p1">
                         <filename>openssh-keycat-8.8p1-35.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-server" release="35.oe2203sp4" version="8.8p1">
                         <filename>openssh-server-8.8p1-35.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pam_ssh_agent_auth" release="4.35.oe2203sp4" version="0.10.4">
                         <filename>pam_ssh_agent_auth-0.10.4-4.35.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1551</id>
          <title>An update for glib2 is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2025-05-23"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-4056" id="CVE-2025-4056" title="CVE-2025-4056" type="cve"></reference>
          </references>
          <description>A vulnerability was found in GNU GLib up to 2.84.0 on Windows (Software Library). It has been rated as problematic. Affected by this issue is some unknown processing of the component Command Line Handler. Upgrading to version 2.84.1 eliminates this vulnerability.(CVE-2025-4056)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="glib2" release="21.oe2203sp4" version="2.72.2">
                         <filename>glib2-2.72.2-21.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glib2-debuginfo" release="21.oe2203sp4" version="2.72.2">
                         <filename>glib2-debuginfo-2.72.2-21.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glib2-debugsource" release="21.oe2203sp4" version="2.72.2">
                         <filename>glib2-debugsource-2.72.2-21.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glib2-devel" release="21.oe2203sp4" version="2.72.2">
                         <filename>glib2-devel-2.72.2-21.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glib2-static" release="21.oe2203sp4" version="2.72.2">
                         <filename>glib2-static-2.72.2-21.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glib2-tests" release="21.oe2203sp4" version="2.72.2">
                         <filename>glib2-tests-2.72.2-21.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="glib2-help" release="21.oe2203sp4" version="2.72.2">
                         <filename>glib2-help-2.72.2-21.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glib2" release="21.oe2203sp4" version="2.72.2">
                         <filename>glib2-2.72.2-21.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glib2-debuginfo" release="21.oe2203sp4" version="2.72.2">
                         <filename>glib2-debuginfo-2.72.2-21.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glib2-debugsource" release="21.oe2203sp4" version="2.72.2">
                         <filename>glib2-debugsource-2.72.2-21.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glib2-devel" release="21.oe2203sp4" version="2.72.2">
                         <filename>glib2-devel-2.72.2-21.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glib2-static" release="21.oe2203sp4" version="2.72.2">
                         <filename>glib2-static-2.72.2-21.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glib2-tests" release="21.oe2203sp4" version="2.72.2">
                         <filename>glib2-tests-2.72.2-21.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1556</id>
          <title>An update for varnish is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-05-23"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-47905" id="CVE-2025-47905" title="CVE-2025-47905" type="cve"></reference>
          </references>
          <description>Varnish Cache before 7.6.3 and 7.7 before 7.7.1, and Varnish Enterprise before 6.0.13r14, allow client-side desync via HTTP/1 requests, because the product incorrectly permits CRLF to be skipped to delimit chunk boundaries.(CVE-2025-47905)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="varnish" release="3.oe2203sp4" version="7.4.3">
                         <filename>varnish-7.4.3-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="varnish-debuginfo" release="3.oe2203sp4" version="7.4.3">
                         <filename>varnish-debuginfo-7.4.3-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="varnish-debugsource" release="3.oe2203sp4" version="7.4.3">
                         <filename>varnish-debugsource-7.4.3-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="varnish-devel" release="3.oe2203sp4" version="7.4.3">
                         <filename>varnish-devel-7.4.3-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="varnish-help" release="3.oe2203sp4" version="7.4.3">
                         <filename>varnish-help-7.4.3-3.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="varnish" release="3.oe2203sp4" version="7.4.3">
                         <filename>varnish-7.4.3-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="varnish-debuginfo" release="3.oe2203sp4" version="7.4.3">
                         <filename>varnish-debuginfo-7.4.3-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="varnish-debugsource" release="3.oe2203sp4" version="7.4.3">
                         <filename>varnish-debugsource-7.4.3-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="varnish-devel" release="3.oe2203sp4" version="7.4.3">
                         <filename>varnish-devel-7.4.3-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1557</id>
          <title>An update for springframework is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-05-23"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22950" id="CVE-2022-22950" title="CVE-2022-22950" type="cve"></reference>
          </references>
          <description>n Spring Framework versions 5.3.0 - 5.3.16 and older unsupported versions, it is possible for a user to provide a specially crafted SpEL expression that may cause a denial of service condition.(CVE-2022-22950)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="springframework" release="14.oe2203sp4" version="3.2.18">
                         <filename>springframework-3.2.18-14.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="springframework-aop" release="14.oe2203sp4" version="3.2.18">
                         <filename>springframework-aop-3.2.18-14.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="springframework-beans" release="14.oe2203sp4" version="3.2.18">
                         <filename>springframework-beans-3.2.18-14.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="springframework-context" release="14.oe2203sp4" version="3.2.18">
                         <filename>springframework-context-3.2.18-14.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="springframework-expression" release="14.oe2203sp4" version="3.2.18">
                         <filename>springframework-expression-3.2.18-14.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="springframework-help" release="14.oe2203sp4" version="3.2.18">
                         <filename>springframework-help-3.2.18-14.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="springframework-instrument" release="14.oe2203sp4" version="3.2.18">
                         <filename>springframework-instrument-3.2.18-14.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="springframework-jdbc" release="14.oe2203sp4" version="3.2.18">
                         <filename>springframework-jdbc-3.2.18-14.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="springframework-jms" release="14.oe2203sp4" version="3.2.18">
                         <filename>springframework-jms-3.2.18-14.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="springframework-orm" release="14.oe2203sp4" version="3.2.18">
                         <filename>springframework-orm-3.2.18-14.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="springframework-orm-hibernate4" release="14.oe2203sp4" version="3.2.18">
                         <filename>springframework-orm-hibernate4-3.2.18-14.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="springframework-oxm" release="14.oe2203sp4" version="3.2.18">
                         <filename>springframework-oxm-3.2.18-14.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="springframework-tx" release="14.oe2203sp4" version="3.2.18">
                         <filename>springframework-tx-3.2.18-14.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="springframework-web" release="14.oe2203sp4" version="3.2.18">
                         <filename>springframework-web-3.2.18-14.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1561</id>
          <title>An update for mod_security is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2025-05-30"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-39956" id="CVE-2022-39956" title="CVE-2022-39956" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-47947" id="CVE-2025-47947" title="CVE-2025-47947" type="cve"></reference>
          </references>
          <description>The OWASP ModSecurity Core Rule Set (CRS) is affected by a partial rule set bypass for HTTP multipart requests by submitting a payload that uses a character encoding scheme via the Content-Type or the deprecated Content-Transfer-Encoding multipart MIME header fields that will not be decoded and inspected by the web application firewall engine and the rule set. The multipart payload will therefore bypass detection. A vulnerable backend that supports these encoding schemes can potentially be exploited. The legacy CRS versions 3.0.x and 3.1.x are affected, as well as the currently supported versions 3.2.1 and 3.3.2. Integrators and users are advised upgrade to 3.2.2 and 3.3.3 respectively. The mitigation against these vulnerabilities depends on the installation of the latest ModSecurity version (v2.9.6 / v3.0.8).(CVE-2022-39956)ModSecurity is an open source, cross platform web application firewall (WAF) engine for Apache, IIS and Nginx. Versions up to and including 2.9.8 are vulnerable to denial of service in one special case (in stable released versions): when the payload&#39;s content type is `application/json`, and there is at least one rule which does a `sanitiseMatchedBytes` action. A patch is available at pull request 3389 and expected to be part of version 2.9.9. No known workarounds are available.(CVE-2025-47947)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="mod_security" release="1.oe2203sp4" version="2.9.9">
                         <filename>mod_security-2.9.9-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_security-debuginfo" release="1.oe2203sp4" version="2.9.9">
                         <filename>mod_security-debuginfo-2.9.9-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_security-debugsource" release="1.oe2203sp4" version="2.9.9">
                         <filename>mod_security-debugsource-2.9.9-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_security" release="1.oe2203sp4" version="2.9.9">
                         <filename>mod_security-2.9.9-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_security-debuginfo" release="1.oe2203sp4" version="2.9.9">
                         <filename>mod_security-debuginfo-2.9.9-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_security-debugsource" release="1.oe2203sp4" version="2.9.9">
                         <filename>mod_security-debugsource-2.9.9-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1567</id>
          <title>An update for libpq is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-05-30"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-4207" id="CVE-2025-4207" title="CVE-2025-4207" type="cve"></reference>
          </references>
          <description>Buffer over-read in PostgreSQL GB18030 encoding validation allows a database input provider to achieve temporary denial of service on platforms where a 1-byte over-read can elicit process termination.  This affects the database server and also libpq.  Versions before PostgreSQL 17.5, 16.9, 15.13, 14.18, and 13.21 are affected.(CVE-2025-4207)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libpq" release="1.oe2203sp4" version="13.21">
                         <filename>libpq-13.21-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libpq-debuginfo" release="1.oe2203sp4" version="13.21">
                         <filename>libpq-debuginfo-13.21-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libpq-debugsource" release="1.oe2203sp4" version="13.21">
                         <filename>libpq-debugsource-13.21-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libpq-devel" release="1.oe2203sp4" version="13.21">
                         <filename>libpq-devel-13.21-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libpq" release="1.oe2203sp4" version="13.21">
                         <filename>libpq-13.21-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libpq-debuginfo" release="1.oe2203sp4" version="13.21">
                         <filename>libpq-debuginfo-13.21-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libpq-debugsource" release="1.oe2203sp4" version="13.21">
                         <filename>libpq-debugsource-13.21-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libpq-devel" release="1.oe2203sp4" version="13.21">
                         <filename>libpq-devel-13.21-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1571</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-05-30"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3238" id="CVE-2022-3238" title="CVE-2022-3238" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53061" id="CVE-2023-53061" title="CVE-2023-53061" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53073" id="CVE-2023-53073" title="CVE-2023-53073" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-57876" id="CVE-2024-57876" title="CVE-2024-57876" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-58097" id="CVE-2024-58097" title="CVE-2024-58097" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37773" id="CVE-2025-37773" title="CVE-2025-37773" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37782" id="CVE-2025-37782" title="CVE-2025-37782" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37925" id="CVE-2025-37925" title="CVE-2025-37925" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37940" id="CVE-2025-37940" title="CVE-2025-37940" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37980" id="CVE-2025-37980" title="CVE-2025-37980" type="cve"></reference>
          </references>
          <description>A double-free flaw was found in the Linux kernel’s NTFS3 subsystem in how a user triggers remount and umount simultaneously. This flaw allows a local user to crash or potentially escalate their privileges on the system.(CVE-2022-3238)In the Linux kernel, the following vulnerability has been resolved:ksmbd: fix possible refcount leak in smb2_open()Reference count of acls will leak when memory allocation fails. Fix thisby adding the missing posix_acl_release().(CVE-2023-53061)In the Linux kernel, the following vulnerability has been resolved:perf/x86/amd/core: Always clear status for idxThe variable &#39;status&#39; (which contains the unhandled overflow bits) isnot being properly masked in some cases, displaying the followingwarning:  WARNING: CPU: 156 PID: 475601 at arch/x86/events/amd/core.c:972 amd_pmu_v2_handle_irq+0x216/0x270This seems to be happening because the loop is being continued beforethe status bit being unset, in case x86_perf_event_set_period()returns 0. This is also causing an inconsistency because the &#34;handled&#34;counter is incremented, but the status bit is not cleaned.Move the bit cleaning together above, together when the &#34;handled&#34;counter is incremented.(CVE-2023-53073)In the Linux kernel, the following vulnerability has been resolved:drm/dp_mst: Fix resetting msg rx state after topology removalIf the MST topology is removed during the reception of an MST down replyor MST up request sideband message, thedrm_dp_mst_topology_mgr::up_req_recv/down_rep_recv states could be resetfrom one thread via drm_dp_mst_topology_mgr_set_mst(false), racing withthe reading/parsing of the message from another thread viadrm_dp_mst_handle_down_rep() or drm_dp_mst_handle_up_req(). The race ispossible since the reader/parser doesn&#39;t hold any lock while accessingthe reception state. This in turn can lead to a memory corruption in thereader/parser as described by commit bd2fccac61b4 (&#34;drm/dp_mst: Fix MSTsideband message body length check&#34;).Fix the above by resetting the message reception state if needed beforereading/parsing a message. Another solution would be to hold thedrm_dp_mst_topology_mgr::lock for the whole duration of the messagereception/parsing in drm_dp_mst_handle_down_rep() anddrm_dp_mst_handle_up_req(), however this would require a bigger change.Since the fix is also needed for stable, opting for the simpler solutionin this patch.(CVE-2024-57876)In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: fix RCU stall while reaping monitor destination ringWhile processing the monitor destination ring, MSDUs are reaped from thelink descriptor based on the corresponding buf_id.However, sometimes the driver cannot obtain a valid buffer correspondingto the buf_id received from the hardware. This causes an infinite loopin the destination processing, resulting in a kernel crash.kernel log:ath11k_pci 0000:58:00.0: data msdu_pop: invalid buf_id 309ath11k_pci 0000:58:00.0: data dp_rx_monitor_link_desc_return failedath11k_pci 0000:58:00.0: data msdu_pop: invalid buf_id 309ath11k_pci 0000:58:00.0: data dp_rx_monitor_link_desc_return failedFix this by skipping the problematic buf_id and reaping the next entry,replacing the break with the next MSDU processing.Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1(CVE-2024-58097)In the Linux kernel, the following vulnerability has been resolved:virtiofs: add filesystem context source name checkIn certain scenarios, for example, during fuzz testing, the sourcename may be NULL, which could lead to a kernel panic. Therefore, anextra check for the source name should be added.(CVE-2025-37773)In the Linux kernel, the following vulnerability has been resolved:hfs/hfsplus: fix slab-out-of-bounds in hfs_bnode_read_keySyzbot reported an issue in hfs subsystem:BUG: KASAN: slab-out-of-bounds in memcpy_from_page include/linux/highmem.h:423 [inline]BUG: KASAN: slab-out-of-bounds in hfs_bnode_read fs/hfs/bnode.c:35 [inline]BUG: KASAN: slab-out-of-bounds in hfs_bnode_read_key+0x314/0x450 fs/hfs/bnode.c:70Write of size 94 at addr ffff8880123cd100 by task syz-executor237/5102Call Trace: &lt;TASK&gt; __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 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+0x40/0x70 mm/kasan/shadow.c:106 memcpy_from_page include/linux/highmem.h:423 [inline] hfs_bnode_read fs/hfs/bnode.c:35 [inline] hfs_bnode_read_key+0x314/0x450 fs/hfs/bnode.c:70 hfs_brec_insert+0x7f3/0xbd0 fs/hfs/brec.c:159 hfs_cat_create+0x41d/0xa50 fs/hfs/catalog.c:118 hfs_mkdir+0x6c/0xe0 fs/hfs/dir.c:232 vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257 do_mkdirat+0x264/0x3a0 fs/namei.c:4280 __do_sys_mkdir fs/namei.c:4300 [inline] __se_sys_mkdir fs/namei.c:4298 [inline] __x64_sys_mkdir+0x6c/0x80 fs/namei.c:4298 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:0x7fbdd6057a99Add a check for key length in hfs_bnode_read_key to preventout-of-bounds memory access. If the key length is invalid, thekey buffer is cleared, improving stability and reliability.(CVE-2025-37782)In the Linux kernel, the following vulnerability has been resolved:jfs: reject on-disk inodes of an unsupported typeSyzbot has reported the following BUG:kernel BUG at fs/inode.c:668!Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTICPU: 3 UID: 0 PID: 139 Comm: jfsCommit Not tainted 6.12.0-rc4-syzkaller-00085-g4e46774408d9 #0Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014RIP: 0010:clear_inode+0x168/0x190Code: 4c 89 f7 e8 ba fe e5 ff e9 61 ff ff ff 44 89 f1 80 e1 07 80 c1 03 38 c1 7c c1 4c 89 f7 e8 90 ff e5 ff eb b7 0b e8 01 5d 7f ff 90 0f 0b e8 f9 5c 7f ff 90 0f 0b e8 f1 5c 7fRSP: 0018:ffffc900027dfae8 EFLAGS: 00010093RAX: ffffffff82157a87 RBX: 0000000000000001 RCX: ffff888104d4b980RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000RBP: ffffc900027dfc90 R08: ffffffff82157977 R09: fffff520004fbf38R10: dffffc0000000000 R11: fffff520004fbf38 R12: dffffc0000000000R13: ffff88811315bc00 R14: ffff88811315bda8 R15: ffff88811315bb80FS:  0000000000000000(0000) GS:ffff888135f00000(0000) knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00005565222e0578 CR3: 0000000026ef0000 CR4: 00000000000006f0Call Trace: &lt;TASK&gt; ? __die_body+0x5f/0xb0 ? die+0x9e/0xc0 ? do_trap+0x15a/0x3a0 ? clear_inode+0x168/0x190 ? do_error_trap+0x1dc/0x2c0 ? clear_inode+0x168/0x190 ? __pfx_do_error_trap+0x10/0x10 ? report_bug+0x3cd/0x500 ? handle_invalid_op+0x34/0x40 ? clear_inode+0x168/0x190 ? exc_invalid_op+0x38/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? clear_inode+0x57/0x190 ? clear_inode+0x167/0x190 ? clear_inode+0x168/0x190 ? clear_inode+0x167/0x190 jfs_evict_inode+0xb5/0x440 ? __pfx_jfs_evict_inode+0x10/0x10 evict+0x4ea/0x9b0 ? __pfx_evict+0x10/0x10 ? iput+0x713/0xa50 txUpdateMap+0x931/0xb10 ? __pfx_txUpdateMap+0x10/0x10 jfs_lazycommit+0x49a/0xb80 ? _raw_spin_unlock_irqrestore+0x8f/0x140 ? lockdep_hardirqs_on+0x99/0x150 ? __pfx_jfs_lazycommit+0x10/0x10 ? __pfx_default_wake_function+0x10/0x10 ? __kthread_parkme+0x169/0x1d0 ? __pfx_jfs_lazycommit+0x10/0x10 kthread+0x2f2/0x390 ? __pfx_jfs_lazycommit+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x4d/0x80 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 &lt;/TASK&gt;This happens when &#39;clear_inode()&#39; makes an attempt to finalize an underlyingJFS inode of unknown type. According to JFS layout description fromhttps://jfs.sourceforge.net/project/pub/jfslayout.pdf, inode types from 5 to15 are reserved for future extensions and should not be encountered on a validfilesystem. So add an extra check for valid inode type in &#39;copy_from_dinode()&#39;.(CVE-2025-37925)In the Linux kernel, the following vulnerability has been resolved:ftrace: Add cond_resched() to ftrace_graph_set_hash()When the kernel contains a large number of functions that can be traced,the loop in ftrace_graph_set_hash() may take a lot of time to execute.This may trigger the softlockup watchdog.Add cond_resched() within the loop to allow the kernel to remainresponsive even when processing a large number of functions.This matches the cond_resched() that is used in other locations of thecode that iterates over all functions that can be traced.(CVE-2025-37940)In the Linux kernel, the following vulnerability has been resolved:block: fix resource leak in blk_register_queue() error pathWhen registering a queue fails after blk_mq_sysfs_register() issuccessful but the function later encounters an error, we needto clean up the blk_mq_sysfs resources.Add the missing blk_mq_sysfs_unregister() call in the error pathto properly clean up these resources and prevent a memory leak.(CVE-2025-37980)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="bpftool" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-265.0.0.168.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-265.0.0.168.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-265.0.0.168.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-265.0.0.168.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-265.0.0.168.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-265.0.0.168.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-265.0.0.168.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-265.0.0.168.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-265.0.0.168.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-265.0.0.168.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-265.0.0.168.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-265.0.0.168.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-265.0.0.168.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-265.0.0.168.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-265.0.0.168.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-265.0.0.168.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-265.0.0.168.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-265.0.0.168.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-265.0.0.168.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-265.0.0.168.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-265.0.0.168.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-265.0.0.168.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-265.0.0.168.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-265.0.0.168.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-265.0.0.168.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-265.0.0.168.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-265.0.0.168.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-265.0.0.168.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-265.0.0.168.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="265.0.0.168.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-265.0.0.168.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1574</id>
          <title>An update for uboot-tools is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-05-30"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-33103" id="CVE-2022-33103" title="CVE-2022-33103" type="cve"></reference>
          </references>
          <description>Das U-Boot from v2020.10 to v2022.07-rc3 was discovered to contain an out-of-bounds write via the function sqfs_readdir().(CVE-2022-33103)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="uboot-images-elf" release="10.oe2203sp4" version="2021.10">
                         <filename>uboot-images-elf-2021.10-10.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="uboot-tools" release="10.oe2203sp4" version="2021.10">
                         <filename>uboot-tools-2021.10-10.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="uboot-tools-debuginfo" release="10.oe2203sp4" version="2021.10">
                         <filename>uboot-tools-debuginfo-2021.10-10.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="uboot-tools-debugsource" release="10.oe2203sp4" version="2021.10">
                         <filename>uboot-tools-debugsource-2021.10-10.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="uboot-images-armv8" release="10.oe2203sp4" version="2021.10">
                         <filename>uboot-images-armv8-2021.10-10.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="uboot-tools-help" release="10.oe2203sp4" version="2021.10">
                         <filename>uboot-tools-help-2021.10-10.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="uboot-tools" release="10.oe2203sp4" version="2021.10">
                         <filename>uboot-tools-2021.10-10.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="uboot-tools-debuginfo" release="10.oe2203sp4" version="2021.10">
                         <filename>uboot-tools-debuginfo-2021.10-10.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="uboot-tools-debugsource" release="10.oe2203sp4" version="2021.10">
                         <filename>uboot-tools-debugsource-2021.10-10.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1578</id>
          <title>An update for binutils is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2025-05-30"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-3198" id="CVE-2025-3198" title="CVE-2025-3198" type="cve"></reference>
          </references>
          <description>A vulnerability has been found in GNU Binutils 2.43/2.44 and classified as problematic. Affected by this vulnerability is the function display_info of the file binutils/bucomm.c of the component objdump. The manipulation leads to memory leak. An attack has to be approached locally. The exploit has been disclosed to the public and may be used. The patch is named ba6ad3a18cb26b79e0e3b84c39f707535bbc344d. It is recommended to apply a patch to fix this issue.(CVE-2025-3198)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="binutils" release="32.oe2203sp4" version="2.37">
                         <filename>binutils-2.37-32.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="binutils-debuginfo" release="32.oe2203sp4" version="2.37">
                         <filename>binutils-debuginfo-2.37-32.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="binutils-debugsource" release="32.oe2203sp4" version="2.37">
                         <filename>binutils-debugsource-2.37-32.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="binutils-devel" release="32.oe2203sp4" version="2.37">
                         <filename>binutils-devel-2.37-32.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="binutils-help" release="32.oe2203sp4" version="2.37">
                         <filename>binutils-help-2.37-32.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="binutils" release="32.oe2203sp4" version="2.37">
                         <filename>binutils-2.37-32.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="binutils-debuginfo" release="32.oe2203sp4" version="2.37">
                         <filename>binutils-debuginfo-2.37-32.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="binutils-debugsource" release="32.oe2203sp4" version="2.37">
                         <filename>binutils-debugsource-2.37-32.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="binutils-devel" release="32.oe2203sp4" version="2.37">
                         <filename>binutils-devel-2.37-32.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="binutils-help" release="32.oe2203sp4" version="2.37">
                         <filename>binutils-help-2.37-32.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1579</id>
          <title>An update for screen is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-05-30"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-46802" id="CVE-2025-46802" title="CVE-2025-46802" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-46804" id="CVE-2025-46804" title="CVE-2025-46804" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-46805" id="CVE-2025-46805" title="CVE-2025-46805" type="cve"></reference>
          </references>
          <description>For a short time they PTY is set to mode 666, allowing any user on the system to connect to the screen session.(CVE-2025-46802)A minor information leak when running Screen with setuid-root privileges allows unprivileged users to deduce information about a path that would otherwise not be available.Affected are older Screen versions, as well as version 5.0.0.(CVE-2025-46804)Screen version 5.0.0 and older version 4 releases have  a TOCTOU race potentially allowing to send SIGHUP, SIGCONT to privileged processes when installed setuid-root.(CVE-2025-46805)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="screen" release="3.oe2203sp4" version="4.9.0">
                         <filename>screen-4.9.0-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="screen-debuginfo" release="3.oe2203sp4" version="4.9.0">
                         <filename>screen-debuginfo-4.9.0-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="screen-debugsource" release="3.oe2203sp4" version="4.9.0">
                         <filename>screen-debugsource-4.9.0-3.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="screen-help" release="3.oe2203sp4" version="4.9.0">
                         <filename>screen-help-4.9.0-3.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="screen" release="3.oe2203sp4" version="4.9.0">
                         <filename>screen-4.9.0-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="screen-debuginfo" release="3.oe2203sp4" version="4.9.0">
                         <filename>screen-debuginfo-4.9.0-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="screen-debugsource" release="3.oe2203sp4" version="4.9.0">
                         <filename>screen-debugsource-4.9.0-3.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1580</id>
          <title>An update for ghostscript is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2025-05-30"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-48708" id="CVE-2025-48708" title="CVE-2025-48708" type="cve"></reference>
          </references>
          <description>gs_lib_ctx_stash_sanitized_arg in base/gslibctx.c in Artifex Ghostscript before 10.05.1 lacks argument sanitization for the # case. A created PDF document includes its password in cleartext.(CVE-2025-48708)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="ghostscript" release="21.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-9.55.0-21.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ghostscript-debuginfo" release="21.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-debuginfo-9.55.0-21.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ghostscript-debugsource" release="21.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-debugsource-9.55.0-21.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ghostscript-devel" release="21.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-devel-9.55.0-21.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ghostscript-tools-dvipdf" release="21.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-tools-dvipdf-9.55.0-21.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="ghostscript-help" release="21.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-help-9.55.0-21.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript" release="21.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-9.55.0-21.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript-debuginfo" release="21.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-debuginfo-9.55.0-21.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript-debugsource" release="21.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-debugsource-9.55.0-21.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript-devel" release="21.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-devel-9.55.0-21.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript-tools-dvipdf" release="21.oe2203sp4" version="9.55.0">
                         <filename>ghostscript-tools-dvipdf-9.55.0-21.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1581</id>
          <title>An update for glibc is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-06-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-4802" id="CVE-2025-4802" title="CVE-2025-4802" type="cve"></reference>
          </references>
          <description>Untrusted LD_LIBRARY_PATH environment variable vulnerability in the GNU C Library version 2.27 to 2.38 allows attacker controlled loading of dynamically shared library in statically compiled setuid binaries that call dlopen (including internal dlopen calls after setlocale or calls to NSS functions such as getaddrinfo).(CVE-2025-4802)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="glibc" release="167.oe2203sp4" version="2.34">
                         <filename>glibc-2.34-167.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-all-langpacks" release="167.oe2203sp4" version="2.34">
                         <filename>glibc-all-langpacks-2.34-167.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-common" release="167.oe2203sp4" version="2.34">
                         <filename>glibc-common-2.34-167.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-compat-2.17" release="167.oe2203sp4" version="2.34">
                         <filename>glibc-compat-2.17-2.34-167.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-debuginfo" release="167.oe2203sp4" version="2.34">
                         <filename>glibc-debuginfo-2.34-167.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-debugsource" release="167.oe2203sp4" version="2.34">
                         <filename>glibc-debugsource-2.34-167.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-debugutils" release="167.oe2203sp4" version="2.34">
                         <filename>glibc-debugutils-2.34-167.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-devel" release="167.oe2203sp4" version="2.34">
                         <filename>glibc-devel-2.34-167.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-locale-archive" release="167.oe2203sp4" version="2.34">
                         <filename>glibc-locale-archive-2.34-167.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-locale-source" release="167.oe2203sp4" version="2.34">
                         <filename>glibc-locale-source-2.34-167.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-nss-devel" release="167.oe2203sp4" version="2.34">
                         <filename>glibc-nss-devel-2.34-167.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libnsl" release="167.oe2203sp4" version="2.34">
                         <filename>libnsl-2.34-167.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="nscd" release="167.oe2203sp4" version="2.34">
                         <filename>nscd-2.34-167.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="nss_modules" release="167.oe2203sp4" version="2.34">
                         <filename>nss_modules-2.34-167.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="glibc-help" release="167.oe2203sp4" version="2.34">
                         <filename>glibc-help-2.34-167.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc" release="167.oe2203sp4" version="2.34">
                         <filename>glibc-2.34-167.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-all-langpacks" release="167.oe2203sp4" version="2.34">
                         <filename>glibc-all-langpacks-2.34-167.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-common" release="167.oe2203sp4" version="2.34">
                         <filename>glibc-common-2.34-167.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-compat-2.17" release="167.oe2203sp4" version="2.34">
                         <filename>glibc-compat-2.17-2.34-167.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-debuginfo" release="167.oe2203sp4" version="2.34">
                         <filename>glibc-debuginfo-2.34-167.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-debugsource" release="167.oe2203sp4" version="2.34">
                         <filename>glibc-debugsource-2.34-167.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-debugutils" release="167.oe2203sp4" version="2.34">
                         <filename>glibc-debugutils-2.34-167.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-devel" release="167.oe2203sp4" version="2.34">
                         <filename>glibc-devel-2.34-167.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-locale-archive" release="167.oe2203sp4" version="2.34">
                         <filename>glibc-locale-archive-2.34-167.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-locale-source" release="167.oe2203sp4" version="2.34">
                         <filename>glibc-locale-source-2.34-167.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-nss-devel" release="167.oe2203sp4" version="2.34">
                         <filename>glibc-nss-devel-2.34-167.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libnsl" release="167.oe2203sp4" version="2.34">
                         <filename>libnsl-2.34-167.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="nscd" release="167.oe2203sp4" version="2.34">
                         <filename>nscd-2.34-167.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="nss_modules" release="167.oe2203sp4" version="2.34">
                         <filename>nss_modules-2.34-167.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1583</id>
          <title>An update for nss is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-06-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22747" id="CVE-2022-22747" title="CVE-2022-22747" type="cve"></reference>
          </references>
          <description>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)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="nss" release="10.oe2203sp4" version="3.72.0">
                         <filename>nss-3.72.0-10.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="nss-debuginfo" release="10.oe2203sp4" version="3.72.0">
                         <filename>nss-debuginfo-3.72.0-10.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="nss-debugsource" release="10.oe2203sp4" version="3.72.0">
                         <filename>nss-debugsource-3.72.0-10.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="nss-devel" release="10.oe2203sp4" version="3.72.0">
                         <filename>nss-devel-3.72.0-10.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="nss-help" release="10.oe2203sp4" version="3.72.0">
                         <filename>nss-help-3.72.0-10.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="nss-softokn" release="10.oe2203sp4" version="3.72.0">
                         <filename>nss-softokn-3.72.0-10.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="nss-softokn-devel" release="10.oe2203sp4" version="3.72.0">
                         <filename>nss-softokn-devel-3.72.0-10.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="nss-util" release="10.oe2203sp4" version="3.72.0">
                         <filename>nss-util-3.72.0-10.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="nss-util-devel" release="10.oe2203sp4" version="3.72.0">
                         <filename>nss-util-devel-3.72.0-10.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="nss" release="10.oe2203sp4" version="3.72.0">
                         <filename>nss-3.72.0-10.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="nss-debuginfo" release="10.oe2203sp4" version="3.72.0">
                         <filename>nss-debuginfo-3.72.0-10.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="nss-debugsource" release="10.oe2203sp4" version="3.72.0">
                         <filename>nss-debugsource-3.72.0-10.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="nss-devel" release="10.oe2203sp4" version="3.72.0">
                         <filename>nss-devel-3.72.0-10.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="nss-help" release="10.oe2203sp4" version="3.72.0">
                         <filename>nss-help-3.72.0-10.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="nss-softokn" release="10.oe2203sp4" version="3.72.0">
                         <filename>nss-softokn-3.72.0-10.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="nss-softokn-devel" release="10.oe2203sp4" version="3.72.0">
                         <filename>nss-softokn-devel-3.72.0-10.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="nss-util" release="10.oe2203sp4" version="3.72.0">
                         <filename>nss-util-3.72.0-10.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="nss-util-devel" release="10.oe2203sp4" version="3.72.0">
                         <filename>nss-util-devel-3.72.0-10.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1586</id>
          <title>An update for nasm is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-06-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38665" id="CVE-2023-38665" title="CVE-2023-38665" type="cve"></reference>
          </references>
          <description>Null pointer dereference in ieee_write_file in nasm 2.16rc0 allows attackers to cause a denial of service (crash).(CVE-2023-38665)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="nasm" release="7.oe2203sp4" version="2.15.05">
                         <filename>nasm-2.15.05-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="nasm-debuginfo" release="7.oe2203sp4" version="2.15.05">
                         <filename>nasm-debuginfo-2.15.05-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="nasm-debugsource" release="7.oe2203sp4" version="2.15.05">
                         <filename>nasm-debugsource-2.15.05-7.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="nasm-help" release="7.oe2203sp4" version="2.15.05">
                         <filename>nasm-help-2.15.05-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="nasm" release="7.oe2203sp4" version="2.15.05">
                         <filename>nasm-2.15.05-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="nasm-debuginfo" release="7.oe2203sp4" version="2.15.05">
                         <filename>nasm-debuginfo-2.15.05-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="nasm-debugsource" release="7.oe2203sp4" version="2.15.05">
                         <filename>nasm-debugsource-2.15.05-7.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1590</id>
          <title>An update for microcode_ctl is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-06-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-23918" id="CVE-2024-23918" title="CVE-2024-23918" type="cve"></reference>
          </references>
          <description>Improper conditions check in some Intel(R) Xeon(R) processor memory controller configurations when using Intel(R) SGX may allow a privileged user to potentially enable escalation of privilege via local access.(CVE-2024-23918)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="x86_64" name="microcode_ctl" release="1.oe2203sp4" version="20250512">
                         <filename>microcode_ctl-20250512-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1591</id>
          <title>An update for perl-YAML-LibYAML is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2025-06-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40908" id="CVE-2025-40908" title="CVE-2025-40908" type="cve"></reference>
          </references>
          <description></description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="perl-YAML-LibYAML" release="2.oe2203sp4" version="0.83">
                         <filename>perl-YAML-LibYAML-0.83-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="perl-YAML-LibYAML-debuginfo" release="2.oe2203sp4" version="0.83">
                         <filename>perl-YAML-LibYAML-debuginfo-0.83-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="perl-YAML-LibYAML-debugsource" release="2.oe2203sp4" version="0.83">
                         <filename>perl-YAML-LibYAML-debugsource-0.83-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="perl-YAML-LibYAML-help" release="2.oe2203sp4" version="0.83">
                         <filename>perl-YAML-LibYAML-help-0.83-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="perl-YAML-LibYAML" release="2.oe2203sp4" version="0.83">
                         <filename>perl-YAML-LibYAML-0.83-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="perl-YAML-LibYAML-debuginfo" release="2.oe2203sp4" version="0.83">
                         <filename>perl-YAML-LibYAML-debuginfo-0.83-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="perl-YAML-LibYAML-debugsource" release="2.oe2203sp4" version="0.83">
                         <filename>perl-YAML-LibYAML-debugsource-0.83-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="perl-YAML-LibYAML-help" release="2.oe2203sp4" version="0.83">
                         <filename>perl-YAML-LibYAML-help-0.83-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1592</id>
          <title>An update for libvpx is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-06-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-5283" id="CVE-2025-5283" title="CVE-2025-5283" type="cve"></reference>
          </references>
          <description>Use after free in libvpx in Google Chrome prior to 137.0.7151.55 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: Medium)(CVE-2025-5283)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libvpx" release="13.oe2203sp4" version="1.7.0">
                         <filename>libvpx-1.7.0-13.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvpx-debuginfo" release="13.oe2203sp4" version="1.7.0">
                         <filename>libvpx-debuginfo-1.7.0-13.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvpx-debugsource" release="13.oe2203sp4" version="1.7.0">
                         <filename>libvpx-debugsource-1.7.0-13.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvpx-devel" release="13.oe2203sp4" version="1.7.0">
                         <filename>libvpx-devel-1.7.0-13.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvpx" release="13.oe2203sp4" version="1.7.0">
                         <filename>libvpx-1.7.0-13.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvpx-debuginfo" release="13.oe2203sp4" version="1.7.0">
                         <filename>libvpx-debuginfo-1.7.0-13.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvpx-debugsource" release="13.oe2203sp4" version="1.7.0">
                         <filename>libvpx-debugsource-1.7.0-13.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvpx-devel" release="13.oe2203sp4" version="1.7.0">
                         <filename>libvpx-devel-1.7.0-13.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1593</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-06-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-49647" id="CVE-2022-49647" title="CVE-2022-49647" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37858" id="CVE-2025-37858" title="CVE-2025-37858" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:cgroup: Use separate src/dst nodes when preloading css_sets for migrationEach cset (css_set) is pinned by its tasks. When we&#39;re moving tasks aroundacross csets for a migration, we need to hold the source and destinationcsets to ensure that they don&#39;t go away while we&#39;re moving tasks about. Thisis done by linking cset-&gt;mg_preload_node on either themgctx-&gt;preloaded_src_csets or mgctx-&gt;preloaded_dst_csets list. Using thesame cset-&gt;mg_preload_node for both the src and dst lists was deemed okay asa cset can&#39;t be both the source and destination at the same time.Unfortunately, this overloading becomes problematic when multiple tasks areinvolved in a migration and some of them are identity noop migrations whileothers are actually moving across cgroups. For example, this can happen withthe following sequence on cgroup1: #1&gt; mkdir -p /sys/fs/cgroup/misc/a/b #2&gt; echo $$ &gt; /sys/fs/cgroup/misc/a/cgroup.procs #3&gt; RUN_A_COMMAND_WHICH_CREATES_MULTIPLE_THREADS &amp; #4&gt; PID=$! #5&gt; echo $PID &gt; /sys/fs/cgroup/misc/a/b/tasks #6&gt; echo $PID &gt; /sys/fs/cgroup/misc/a/cgroup.procsthe process including the group leader back into a. In this final migration,non-leader threads would be doing identity migration while the group leaderis doing an actual one.After #3, let&#39;s say the whole process was in cset A, and that after #4, theleader moves to cset B. Then, during #6, the following happens: 1. cgroup_migrate_add_src() is called on B for the leader. 2. cgroup_migrate_add_src() is called on A for the other threads. 3. cgroup_migrate_prepare_dst() is called. It scans the src list. 4. It notices that B wants to migrate to A, so it tries to A to the dst    list but realizes that its -&gt;mg_preload_node is already busy. 5. and then it notices A wants to migrate to A as it&#39;s an identity    migration, it culls it by list_del_init()&#39;ing its -&gt;mg_preload_node and    putting references accordingly. 6. The rest of migration takes place with B on the src list but nothing on    the dst list.This means that A isn&#39;t held while migration is in progress. If all tasksleave A before the migration finishes and the incoming task pins it, thecset will be destroyed leading to use-after-free.This is caused by overloading cset-&gt;mg_preload_node for both src and dstpreload lists. We wanted to exclude the cset from the src list but ended upinadvertently excluding it from the dst list too.This patch fixes the issue by separating out cset-&gt;mg_preload_node into-&gt;mg_src_preload_node and -&gt;mg_dst_preload_node, so that the src and dstpreloadings don&#39;t interfere with each other.(CVE-2022-49647)In the Linux kernel, the following vulnerability has been resolved:fs/jfs: Prevent integer overflow in AG size calculationThe JFS filesystem calculates allocation group (AG) size using 1 &lt;&lt;l2agsize in dbExtendFS(). When l2agsize exceeds 31 (possible with &gt;2TBaggregates on 32-bit systems), this 32-bit shift operation causes undefinedbehavior and improper AG sizing.On 32-bit architectures:- Left-shifting 1 by 32+ bits results in 0 due to integer overflow- This creates invalid AG sizes (0 or garbage values) insbi-&gt;bmap-&gt;db_agsize- Subsequent block allocations would reference invalid AG structures- Could lead to:  - Filesystem corruption during extend operations  - Kernel crashes due to invalid memory accesses  - Security vulnerabilities via malformed on-disk structuresFix by casting to s64 before shifting:bmp-&gt;db_agsize = (s64)1 &lt;&lt; l2agsize;This ensures 64-bit arithmetic even on 32-bit architectures. The castmatches the data type of db_agsize (s64) and follows similar patterns inJFS block calculation code.Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37858)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="bpftool" release="266.0.0.169.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-266.0.0.169.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="266.0.0.169.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-266.0.0.169.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="266.0.0.169.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-266.0.0.169.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="266.0.0.169.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-266.0.0.169.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="266.0.0.169.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-266.0.0.169.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="266.0.0.169.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-266.0.0.169.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="266.0.0.169.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-266.0.0.169.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="266.0.0.169.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-266.0.0.169.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="266.0.0.169.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-266.0.0.169.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="266.0.0.169.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-266.0.0.169.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="266.0.0.169.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-266.0.0.169.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="266.0.0.169.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-266.0.0.169.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="266.0.0.169.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-266.0.0.169.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="266.0.0.169.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-266.0.0.169.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="266.0.0.169.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-266.0.0.169.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="266.0.0.169.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-266.0.0.169.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="266.0.0.169.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-266.0.0.169.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="266.0.0.169.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-266.0.0.169.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="266.0.0.169.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-266.0.0.169.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="266.0.0.169.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-266.0.0.169.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="266.0.0.169.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-266.0.0.169.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="266.0.0.169.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-266.0.0.169.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="266.0.0.169.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-266.0.0.169.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="266.0.0.169.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-266.0.0.169.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="266.0.0.169.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-266.0.0.169.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="266.0.0.169.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-266.0.0.169.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="266.0.0.169.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-266.0.0.169.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="266.0.0.169.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-266.0.0.169.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="266.0.0.169.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-266.0.0.169.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="266.0.0.169.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-266.0.0.169.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1600</id>
          <title>An update for pam is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-06-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-10041" id="CVE-2024-10041" title="CVE-2024-10041" type="cve"></reference>
          </references>
          <description>A vulnerability was found in PAM. The secret information is stored in memory, where the attacker can trigger the victim program to execute by sending characters to its standard input (stdin). As this occurs, the attacker can train the branch predictor to execute an ROP chain speculatively. This flaw could result in leaked passwords, such as those found in /etc/shadow while performing authentications.(CVE-2024-10041)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="pam" release="12.oe2203sp4" version="1.5.2">
                         <filename>pam-1.5.2-12.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pam-debuginfo" release="12.oe2203sp4" version="1.5.2">
                         <filename>pam-debuginfo-1.5.2-12.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pam-debugsource" release="12.oe2203sp4" version="1.5.2">
                         <filename>pam-debugsource-1.5.2-12.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pam-devel" release="12.oe2203sp4" version="1.5.2">
                         <filename>pam-devel-1.5.2-12.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="pam-help" release="12.oe2203sp4" version="1.5.2">
                         <filename>pam-help-1.5.2-12.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pam" release="12.oe2203sp4" version="1.5.2">
                         <filename>pam-1.5.2-12.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pam-debuginfo" release="12.oe2203sp4" version="1.5.2">
                         <filename>pam-debuginfo-1.5.2-12.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pam-debugsource" release="12.oe2203sp4" version="1.5.2">
                         <filename>pam-debugsource-1.5.2-12.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pam-devel" release="12.oe2203sp4" version="1.5.2">
                         <filename>pam-devel-1.5.2-12.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1605</id>
          <title>An update for firefox is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-06-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5689" id="CVE-2024-5689" title="CVE-2024-5689" type="cve"></reference>
          </references>
          <description>In addition to detecting when a user was taking a screenshot (XXX), a website was able to overlay the &#39;My Shots&#39; button that appeared, and direct the user to a replica Firefox Screenshots page that could be used for phishing. This vulnerability affects Firefox &lt; 127.(CVE-2024-5689)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="firefox" release="1.oe2203sp4" version="128.10.1">
                         <filename>firefox-128.10.1-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="firefox-debuginfo" release="1.oe2203sp4" version="128.10.1">
                         <filename>firefox-debuginfo-128.10.1-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="firefox-debugsource" release="1.oe2203sp4" version="128.10.1">
                         <filename>firefox-debugsource-128.10.1-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox" release="1.oe2203sp4" version="128.10.1">
                         <filename>firefox-128.10.1-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox-debuginfo" release="1.oe2203sp4" version="128.10.1">
                         <filename>firefox-debuginfo-128.10.1-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox-debugsource" release="1.oe2203sp4" version="128.10.1">
                         <filename>firefox-debugsource-128.10.1-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1606</id>
          <title>An update for yelp is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-06-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-3155" id="CVE-2025-3155" title="CVE-2025-3155" type="cve"></reference>
          </references>
          <description>A flaw was found in Yelp. The Gnome user help application allows the help document to execute arbitrary scripts. This vulnerability allows malicious users to input help documents, which may exfiltrate user files to an external environment.(CVE-2025-3155)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="2" arch="aarch64" name="yelp" release="2.oe2203sp4" version="3.38.3">
                         <filename>yelp-3.38.3-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="yelp-debuginfo" release="2.oe2203sp4" version="3.38.3">
                         <filename>yelp-debuginfo-3.38.3-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="yelp-debugsource" release="2.oe2203sp4" version="3.38.3">
                         <filename>yelp-debugsource-3.38.3-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="yelp-devel" release="2.oe2203sp4" version="3.38.3">
                         <filename>yelp-devel-3.38.3-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="noarch" name="yelp-help" release="2.oe2203sp4" version="3.38.3">
                         <filename>yelp-help-3.38.3-2.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="yelp" release="2.oe2203sp4" version="3.38.3">
                         <filename>yelp-3.38.3-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="yelp-debuginfo" release="2.oe2203sp4" version="3.38.3">
                         <filename>yelp-debuginfo-3.38.3-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="yelp-debugsource" release="2.oe2203sp4" version="3.38.3">
                         <filename>yelp-debugsource-3.38.3-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="yelp-devel" release="2.oe2203sp4" version="3.38.3">
                         <filename>yelp-devel-3.38.3-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1610</id>
          <title>An update for cpp-httplib is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-06-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-46728" id="CVE-2025-46728" title="CVE-2025-46728" type="cve"></reference>
          </references>
          <description>cpp-httplib is a C++ header-only HTTP/HTTPS server and client library. Prior to version 0.20.1, the library fails to enforce configured size limits on incoming request bodies when `Transfer-Encoding: chunked` is used or when no `Content-Length` header is provided. A remote attacker can send a chunked request without the terminating zero-length chunk, causing uncontrolled memory allocation on the server. This leads to potential exhaustion of system memory and results in a server crash or unresponsiveness. Version 0.20.1 fixes the issue by enforcing limits during parsing. If the limit is exceeded at any point during reading, the connection is terminated immediately. A short-term workaround through a Reverse Proxy is available. If updating the library immediately is not feasible, deploy a reverse proxy (e.g., Nginx, HAProxy) in front of the `cpp-httplib` application. Configure the proxy to enforce maximum request body size limits, thereby stopping excessively large requests before they reach the vulnerable library code.(CVE-2025-46728)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="cpp-httplib" release="4.oe2203sp4" version="0.12.4">
                         <filename>cpp-httplib-0.12.4-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cpp-httplib" release="4.oe2203sp4" version="0.12.4">
                         <filename>cpp-httplib-0.12.4-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1615</id>
          <title>An update for python-tornado is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-06-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-47287" id="CVE-2025-47287" title="CVE-2025-47287" type="cve"></reference>
          </references>
          <description>Tornado is a Python web framework and asynchronous networking library. When Tornado&#39;s ``multipart/form-data`` parser encounters certain errors, it logs a warning but continues trying to parse the remainder of the data. This allows remote attackers to generate an extremely high volume of logs, constituting a DoS attack. This DoS is compounded by the fact that the logging subsystem is synchronous. All versions of Tornado prior to 6.5.0 are affected. The vulnerable parser is enabled by default. Upgrade to Tornado version 6.50 to receive a patch. As a workaround, risk can be mitigated by blocking `Content-Type: multipart/form-data` in a proxy.(CVE-2025-47287)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="python-tornado-debuginfo" release="4.oe2203sp4" version="6.1">
                         <filename>python-tornado-debuginfo-6.1-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python-tornado-debugsource" release="4.oe2203sp4" version="6.1">
                         <filename>python-tornado-debugsource-6.1-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python-tornado-help" release="4.oe2203sp4" version="6.1">
                         <filename>python-tornado-help-6.1-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-tornado" release="4.oe2203sp4" version="6.1">
                         <filename>python3-tornado-6.1-4.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python-tornado-debuginfo" release="4.oe2203sp4" version="6.1">
                         <filename>python-tornado-debuginfo-6.1-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python-tornado-debugsource" release="4.oe2203sp4" version="6.1">
                         <filename>python-tornado-debugsource-6.1-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python-tornado-help" release="4.oe2203sp4" version="6.1">
                         <filename>python-tornado-help-6.1-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-tornado" release="4.oe2203sp4" version="6.1">
                         <filename>python3-tornado-6.1-4.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1616</id>
          <title>An update for gstreamer1-plugins-base is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-06-13"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-47806" id="CVE-2025-47806" title="CVE-2025-47806" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-47807" id="CVE-2025-47807" title="CVE-2025-47807" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-47808" id="CVE-2025-47808" title="CVE-2025-47808" type="cve"></reference>
          </references>
          <description>(CVE-2025-47806)(CVE-2025-47807)(CVE-2025-47808)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="gstreamer1-plugins-base" release="9.oe2203sp4" version="1.18.4">
                         <filename>gstreamer1-plugins-base-1.18.4-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gstreamer1-plugins-base-debuginfo" release="9.oe2203sp4" version="1.18.4">
                         <filename>gstreamer1-plugins-base-debuginfo-1.18.4-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gstreamer1-plugins-base-debugsource" release="9.oe2203sp4" version="1.18.4">
                         <filename>gstreamer1-plugins-base-debugsource-1.18.4-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gstreamer1-plugins-base-devel" release="9.oe2203sp4" version="1.18.4">
                         <filename>gstreamer1-plugins-base-devel-1.18.4-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="gstreamer1-plugins-base-help" release="9.oe2203sp4" version="1.18.4">
                         <filename>gstreamer1-plugins-base-help-1.18.4-9.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gstreamer1-plugins-base" release="9.oe2203sp4" version="1.18.4">
                         <filename>gstreamer1-plugins-base-1.18.4-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gstreamer1-plugins-base-debuginfo" release="9.oe2203sp4" version="1.18.4">
                         <filename>gstreamer1-plugins-base-debuginfo-1.18.4-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gstreamer1-plugins-base-debugsource" release="9.oe2203sp4" version="1.18.4">
                         <filename>gstreamer1-plugins-base-debugsource-1.18.4-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gstreamer1-plugins-base-devel" release="9.oe2203sp4" version="1.18.4">
                         <filename>gstreamer1-plugins-base-devel-1.18.4-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1619</id>
          <title>An update for python-django is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-06-13"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-48432" id="CVE-2025-48432" title="CVE-2025-48432" type="cve"></reference>
          </references>
          <description>A vulnerability, which was classified as problematic, was found in Django up to 4.2.21/5.1.9/5.2.1 (Content Management System).CWE is classifying the issue as CWE-117. The product does not neutralize or incorrectly neutralizes output that is written to logs.This is going to have an impact on integrity.Upgrading to version 4.2.22, 5.1.10 or 5.2.2 eliminates this vulnerability.(CVE-2025-48432)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="python-django-help" release="7.oe2203sp4" version="4.2.15">
                         <filename>python-django-help-4.2.15-7.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-Django" release="7.oe2203sp4" version="4.2.15">
                         <filename>python3-Django-4.2.15-7.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1628</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-06-13"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53082" id="CVE-2023-53082" title="CVE-2023-53082" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-23148" id="CVE-2025-23148" title="CVE-2025-23148" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-23156" id="CVE-2025-23156" title="CVE-2025-23156" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37923" id="CVE-2025-37923" title="CVE-2025-37923" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-37995" id="CVE-2025-37995" title="CVE-2025-37995" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:vp_vdpa: fix the crash in hot unplug with vp_vdpaWhile unplugging the vp_vdpa device, it triggers a kernel panicThe root cause is: vdpa_mgmtdev_unregister() will accesses moderndevices which will cause a use after free.So need to change the sequence in vp_vdpa_remove[  195.003359] BUG: unable to handle page fault for address: ff4e8beb80199014[  195.004012] #PF: supervisor read access in kernel mode[  195.004486] #PF: error_code(0x0000) - not-present page[  195.004960] PGD 100000067 P4D 1001b6067 PUD 1001b7067 PMD 1001b8067 PTE 0[  195.005578] Oops: 0000 1 PREEMPT SMP PTI[  195.005968] CPU: 13 PID: 164 Comm: kworker/u56:10 Kdump: loaded Not tainted 5.14.0-252.el9.x86_64 #1[  195.006792] Hardware name: Red Hat KVM/RHEL, BIOS edk2-20221207gitfff6d81270b5-2.el9 unknown[  195.007556] Workqueue: kacpi_hotplug acpi_hotplug_work_fn[  195.008059] RIP: 0010:ioread8+0x31/0x80[  195.008418] Code: 77 28 48 81 ff 00 00 01 00 76 0b 89 fa ec 0f b6 c0 c3 cc cc cc cc 8b 15 ad 72 93 01 b8 ff 00 00 00 85 d2 75 0f c3 cc cc cc cc &lt;8a&gt; 07 0f b6 c0 c3 cc cc cc cc 83 ea 01 48 83 ec 08 48 89 fe 48 c7[  195.010104] RSP: 0018:ff4e8beb8067bab8 EFLAGS: 00010292[  195.010584] RAX: ffffffffc05834a0 RBX: ffffffffc05843c0 RCX: ff4e8beb8067bae0[  195.011233] RDX: ff1bcbd580f88000 RSI: 0000000000000246 RDI: ff4e8beb80199014[  195.011881] RBP: ff1bcbd587e39000 R08: ffffffff916fa2d0 R09: ff4e8beb8067ba68[  195.012527] R10: 000000000000001c R11: 0000000000000000 R12: ff1bcbd5a3de9120[  195.013179] R13: ffffffffc062d000 R14: 0000000000000080 R15: ff1bcbe402bc7805[  195.013826] FS:  0000000000000000(0000) GS:ff1bcbe402740000(0000) knlGS:0000000000000000[  195.014564] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033[  195.015093] CR2: ff4e8beb80199014 CR3: 0000000107dea002 CR4: 0000000000771ee0[  195.015741] PKRU: 55555554[  195.016001] Call Trace:[  195.016233]  &lt;TASK&gt;[  195.016434]  vp_modern_get_status+0x12/0x20[  195.016823]  vp_vdpa_reset+0x1b/0x50 [vp_vdpa][  195.017238]  virtio_vdpa_reset+0x3c/0x48 [virtio_vdpa][  195.017709]  remove_vq_common+0x1f/0x3a0 [virtio_net][  195.018178]  virtnet_remove+0x5d/0x70 [virtio_net][  195.018618]  virtio_dev_remove+0x3d/0x90[  195.018986]  device_release_driver_internal+0x1aa/0x230[  195.019466]  bus_remove_device+0xd8/0x150[  195.019841]  device_del+0x18b/0x3f0[  195.020167]  ? kernfs_find_ns+0x35/0xd0[  195.020526]  device_unregister+0x13/0x60[  195.020894]  unregister_virtio_device+0x11/0x20[  195.021311]  device_release_driver_internal+0x1aa/0x230[  195.021790]  bus_remove_device+0xd8/0x150[  195.022162]  device_del+0x18b/0x3f0[  195.022487]  device_unregister+0x13/0x60[  195.022852]  ? vdpa_dev_remove+0x30/0x30 [vdpa][  195.023270]  vp_vdpa_dev_del+0x12/0x20 [vp_vdpa][  195.023694]  vdpa_match_remove+0x2b/0x40 [vdpa][  195.024115]  bus_for_each_dev+0x78/0xc0[  195.024471]  vdpa_mgmtdev_unregister+0x65/0x80 [vdpa][  195.024937]  vp_vdpa_remove+0x23/0x40 [vp_vdpa][  195.025353]  pci_device_remove+0x36/0xa0[  195.025719]  device_release_driver_internal+0x1aa/0x230[  195.026201]  pci_stop_bus_device+0x6c/0x90[  195.026580]  pci_stop_and_remove_bus_device+0xe/0x20[  195.027039]  disable_slot+0x49/0x90[  195.027366]  acpiphp_disable_and_eject_slot+0x15/0x90[  195.027832]  hotplug_event+0xea/0x210[  195.028171]  ? hotplug_event+0x210/0x210[  195.028535]  acpiphp_hotplug_notify+0x22/0x80[  195.028942]  ? hotplug_event+0x210/0x210[  195.029303]  acpi_device_hotplug+0x8a/0x1d0[  195.029690]  acpi_hotplug_work_fn+0x1a/0x30[  195.030077]  process_one_work+0x1e8/0x3c0[  195.030451]  worker_thread+0x50/0x3b0[  195.030791]  ? rescuer_thread+0x3a0/0x3a0[  195.031165]  kthread+0xd9/0x100[  195.031459]  ? kthread_complete_and_exit+0x20/0x20[  195.031899]  ret_from_fork+0x22/0x30[  195.032233]  &lt;/TASK&gt;(CVE-2023-53082)In the Linux kernel, the following vulnerability has been resolved:soc: samsung: exynos-chipid: Add NULL pointer check in exynos_chipid_probe()soc_dev_attr-&gt;revision could be NULL, thus,a pointer check is added to prevent potential NULL pointer dereference.This is similar to the fix in commit 3027e7b15b02(&#34;ice: Fix some null pointer dereference issues in ice_ptp.c&#34;).This issue is found by our static analysis tool.(CVE-2025-23148)In the Linux kernel, the following vulnerability has been resolved:media: venus: hfi_parser: refactor hfi packet parsing logicwords_count denotes the number of words in total payload, while datapoints to payload of various property within it. When words_countreaches last word, data can access memory beyond the total payload. Thiscan lead to OOB access. With this patch, the utility api for handlingindividual properties now returns the size of data consumed. Accordinglyremaining bytes are calculated before parsing the payload, therebyeliminates the OOB access possibilities.(CVE-2025-23156)In the Linux kernel, the following vulnerability has been resolved:tracing: Fix oob write in trace_seq_to_buffer()syzbot reported this bug:==================================================================BUG: KASAN: slab-out-of-bounds in trace_seq_to_buffer kernel/trace/trace.c:1830 [inline]BUG: KASAN: slab-out-of-bounds in tracing_splice_read_pipe+0x6be/0xdd0 kernel/trace/trace.c:6822Write of size 4507 at addr ffff888032b6b000 by task syz.2.320/7260CPU: 1 UID: 0 PID: 7260 Comm: syz.2.320 Not tainted 6.15.0-rc1-syzkaller-00301-g3bde70a2c827 #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025Call Trace: &lt;TASK&gt; __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xc3/0x670 mm/kasan/report.c:521 kasan_report+0xe0/0x110 mm/kasan/report.c:634 check_region_inline mm/kasan/generic.c:183 [inline] kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189 __asan_memcpy+0x3c/0x60 mm/kasan/shadow.c:106 trace_seq_to_buffer kernel/trace/trace.c:1830 [inline] tracing_splice_read_pipe+0x6be/0xdd0 kernel/trace/trace.c:6822 ....==================================================================It has been reported that trace_seq_to_buffer() tries to copy more datathan PAGE_SIZE to buf. Therefore, to prevent this, we should use thesmaller of trace_seq_used(&amp;iter-&gt;seq) and PAGE_SIZE as an argument.(CVE-2025-37923)In the Linux kernel, the following vulnerability has been resolved:module: ensure that kobject_put() is safe for module type kobjectsIn &#39;lookup_or_create_module_kobject()&#39;, an internal kobject is createdusing &#39;module_ktype&#39;. So call to &#39;kobject_put()&#39; on error handlingpath causes an attempt to use an uninitialized completion pointer in&#39;module_kobject_release()&#39;. In this scenario, we just want to releasekobject without an extra synchronization required for a regular moduleunloading process, so adding an extra check whether &#39;complete()&#39; isactually required makes &#39;kobject_put()&#39; safe.(CVE-2025-37995)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="bpftool" release="267.0.0.170.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-267.0.0.170.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="267.0.0.170.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-267.0.0.170.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="267.0.0.170.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-267.0.0.170.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="267.0.0.170.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-267.0.0.170.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="267.0.0.170.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-267.0.0.170.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="267.0.0.170.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-267.0.0.170.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="267.0.0.170.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-267.0.0.170.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="267.0.0.170.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-267.0.0.170.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="267.0.0.170.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-267.0.0.170.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="267.0.0.170.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-267.0.0.170.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="267.0.0.170.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-267.0.0.170.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="267.0.0.170.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-267.0.0.170.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="267.0.0.170.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-267.0.0.170.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="267.0.0.170.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-267.0.0.170.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="267.0.0.170.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-267.0.0.170.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="267.0.0.170.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-267.0.0.170.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="267.0.0.170.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-267.0.0.170.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="267.0.0.170.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-267.0.0.170.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="267.0.0.170.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-267.0.0.170.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="267.0.0.170.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-267.0.0.170.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="267.0.0.170.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-267.0.0.170.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="267.0.0.170.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-267.0.0.170.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="267.0.0.170.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-267.0.0.170.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="267.0.0.170.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-267.0.0.170.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="267.0.0.170.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-267.0.0.170.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="267.0.0.170.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-267.0.0.170.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="267.0.0.170.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-267.0.0.170.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="267.0.0.170.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-267.0.0.170.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="267.0.0.170.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-267.0.0.170.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="267.0.0.170.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-267.0.0.170.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1630</id>
          <title>An update for redis is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-06-13"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-27151" id="CVE-2025-27151" title="CVE-2025-27151" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-49112" id="CVE-2025-49112" title="CVE-2025-49112" type="cve"></reference>
          </references>
          <description>Redis is an open source, in-memory database that persists on disk. In versions starting from 7.0.0 to before 8.0.2, a stack-based buffer overflow exists in redis-check-aof due to the use of memcpy with strlen(filepath) when copying a user-supplied file path into a fixed-size stack buffer. This allows an attacker to overflow the stack and potentially achieve code execution. This issue has been patched in version 8.0.2.(CVE-2025-27151)setDeferredReply in networking.c in Valkey through 8.1.1 has an integer underflow for prev-&gt;size - prev-&gt;used.(CVE-2025-49112)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="redis" release="2.oe2203sp4" version="7.2.9">
                         <filename>redis-7.2.9-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="redis-debuginfo" release="2.oe2203sp4" version="7.2.9">
                         <filename>redis-debuginfo-7.2.9-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="redis-debugsource" release="2.oe2203sp4" version="7.2.9">
                         <filename>redis-debugsource-7.2.9-2.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="redis" release="2.oe2203sp4" version="7.2.9">
                         <filename>redis-7.2.9-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="redis-debuginfo" release="2.oe2203sp4" version="7.2.9">
                         <filename>redis-debuginfo-7.2.9-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="redis-debugsource" release="2.oe2203sp4" version="7.2.9">
                         <filename>redis-debugsource-7.2.9-2.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1631</id>
          <title>An update for perl is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-06-13"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-40909" id="CVE-2025-40909" title="CVE-2025-40909" type="cve"></reference>
          </references>
          <description>Perl threads have a working directory race condition where file operations may target unintended paths.If a directory handle is open at thread creation, the process-wide current working directory is temporarily changed in order to clone that handle for the new thread, which is visible from any third (or more) thread already running. This may lead to unintended operations such as loading code or accessing files from unexpected locations, which a local attacker may be able to exploit.The bug was introduced in commit 11a11ecf4bea72b17d250cfb43c897be1341861e and released in Perl version 5.13.6(CVE-2025-40909)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="4" arch="aarch64" name="perl" release="14.oe2203sp4" version="5.34.0">
                         <filename>perl-5.34.0-14.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="4" arch="aarch64" name="perl-debuginfo" release="14.oe2203sp4" version="5.34.0">
                         <filename>perl-debuginfo-5.34.0-14.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="4" arch="aarch64" name="perl-debugsource" release="14.oe2203sp4" version="5.34.0">
                         <filename>perl-debugsource-5.34.0-14.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="4" arch="aarch64" name="perl-devel" release="14.oe2203sp4" version="5.34.0">
                         <filename>perl-devel-5.34.0-14.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="4" arch="aarch64" name="perl-libs" release="14.oe2203sp4" version="5.34.0">
                         <filename>perl-libs-5.34.0-14.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package epoch="4" arch="noarch" name="perl-help" release="14.oe2203sp4" version="5.34.0">
                         <filename>perl-help-5.34.0-14.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="4" arch="x86_64" name="perl" release="14.oe2203sp4" version="5.34.0">
                         <filename>perl-5.34.0-14.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="4" arch="x86_64" name="perl-debuginfo" release="14.oe2203sp4" version="5.34.0">
                         <filename>perl-debuginfo-5.34.0-14.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="4" arch="x86_64" name="perl-debugsource" release="14.oe2203sp4" version="5.34.0">
                         <filename>perl-debugsource-5.34.0-14.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="4" arch="x86_64" name="perl-devel" release="14.oe2203sp4" version="5.34.0">
                         <filename>perl-devel-5.34.0-14.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package epoch="4" arch="x86_64" name="perl-libs" release="14.oe2203sp4" version="5.34.0">
                         <filename>perl-libs-5.34.0-14.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1632</id>
          <title>An update for libsoup is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-06-13"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-4476" id="CVE-2025-4476" title="CVE-2025-4476" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-4948" id="CVE-2025-4948" title="CVE-2025-4948" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-4969" id="CVE-2025-4969" title="CVE-2025-4969" type="cve"></reference>
          </references>
          <description>A denial-of-service vulnerability has been identified in the libsoup HTTP client library. This flaw can be triggered when a libsoup client receives a 401 (Unauthorized) HTTP response containing a specifically crafted domain parameter within the WWW-Authenticate header. Processing this malformed header can lead to a crash of the client application using libsoup. An attacker could exploit this by setting up a malicious HTTP server. If a user&#39;s application using the vulnerable libsoup library connects to this malicious server, it could result in a denial-of-service. Successful exploitation requires tricking a user&#39;s client application into connecting to the attacker&#39;s malicious server.(CVE-2025-4476)A flaw was found in the soup_multipart_new_from_message() function of the libsoup HTTP library, which is commonly used by GNOME and other applications to handle web communications. The issue occurs when the library processes specially crafted multipart messages. Due to improper validation, an internal calculation can go wrong, leading to an integer underflow. This can cause the program to access invalid memory and crash. As a result, any application or server using libsoup could be forced to exit unexpectedly, creating a denial-of-service (DoS) risk.(CVE-2025-4948)A vulnerability was found in the libsoup package. This flaw stems from its failure to correctly verify the termination of multipart HTTP messages. This can allow a remote attacker to send a specially crafted multipart HTTP body, causing the libsoup-consuming server to read beyond its allocated memory boundaries (out-of-bounds read).(CVE-2025-4969)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libsoup" release="10.oe2203sp4" version="2.74.2">
                         <filename>libsoup-2.74.2-10.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libsoup-debuginfo" release="10.oe2203sp4" version="2.74.2">
                         <filename>libsoup-debuginfo-2.74.2-10.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libsoup-debugsource" release="10.oe2203sp4" version="2.74.2">
                         <filename>libsoup-debugsource-2.74.2-10.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libsoup-devel" release="10.oe2203sp4" version="2.74.2">
                         <filename>libsoup-devel-2.74.2-10.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="libsoup-help" release="10.oe2203sp4" version="2.74.2">
                         <filename>libsoup-help-2.74.2-10.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libsoup" release="10.oe2203sp4" version="2.74.2">
                         <filename>libsoup-2.74.2-10.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libsoup-debuginfo" release="10.oe2203sp4" version="2.74.2">
                         <filename>libsoup-debuginfo-2.74.2-10.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libsoup-debugsource" release="10.oe2203sp4" version="2.74.2">
                         <filename>libsoup-debugsource-2.74.2-10.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libsoup-devel" release="10.oe2203sp4" version="2.74.2">
                         <filename>libsoup-devel-2.74.2-10.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1635</id>
          <title>An update for firefox is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-06-13"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-5263" id="CVE-2025-5263" title="CVE-2025-5263" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-5264" id="CVE-2025-5264" title="CVE-2025-5264" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-5266" id="CVE-2025-5266" title="CVE-2025-5266" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-5267" id="CVE-2025-5267" title="CVE-2025-5267" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-5268" id="CVE-2025-5268" title="CVE-2025-5268" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-5269" id="CVE-2025-5269" title="CVE-2025-5269" type="cve"></reference>
          </references>
          <description>Error handling for script execution was incorrectly isolated from web content, which could have allowed cross-origin leak attacks. This vulnerability affects Firefox &lt; 139, Firefox ESR &lt; 115.24, Firefox ESR &lt; 128.11, Thunderbird &lt; 139, and Thunderbird &lt; 128.11.(CVE-2025-5263)Due to insufficient escaping of the newline character in the “Copy as cURL” feature, an attacker could trick a user into using this command, potentially leading to local code execution on the user&#39;s system. This vulnerability affects Firefox &lt; 139, Firefox ESR &lt; 115.24, Firefox ESR &lt; 128.11, Thunderbird &lt; 139, and Thunderbird &lt; 128.11.(CVE-2025-5264)Script elements loading cross-origin resources generated load and error events which leaked information enabling XS-Leaks attacks. This vulnerability affects Firefox &lt; 139, Firefox ESR &lt; 128.11, Thunderbird &lt; 139, and Thunderbird &lt; 128.11.(CVE-2025-5266)A clickjacking vulnerability could have been used to trick a user into leaking saved payment card details to a malicious page. This vulnerability affects Firefox &lt; 139, Firefox ESR &lt; 128.11, Thunderbird &lt; 139, and Thunderbird &lt; 128.11.(CVE-2025-5267)Memory safety bugs present in Firefox 138, Thunderbird 138, Firefox ESR 128.10, and Thunderbird 128.10. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox &lt; 139, Firefox ESR &lt; 128.11, Thunderbird &lt; 139, and Thunderbird &lt; 128.11.(CVE-2025-5268)Memory safety bug present in Firefox ESR 128.10, and Thunderbird 128.10. This bug showed evidence of memory corruption and we presume that with enough effort this could have been exploited to run arbitrary code. This vulnerability affects Firefox ESR &lt; 128.11 and Thunderbird &lt; 128.11.(CVE-2025-5269)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="firefox" release="1.oe2203sp4" version="128.11.0">
                         <filename>firefox-128.11.0-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="firefox-debuginfo" release="1.oe2203sp4" version="128.11.0">
                         <filename>firefox-debuginfo-128.11.0-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="firefox-debugsource" release="1.oe2203sp4" version="128.11.0">
                         <filename>firefox-debugsource-128.11.0-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox" release="1.oe2203sp4" version="128.11.0">
                         <filename>firefox-128.11.0-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox-debuginfo" release="1.oe2203sp4" version="128.11.0">
                         <filename>firefox-debuginfo-128.11.0-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox-debugsource" release="1.oe2203sp4" version="128.11.0">
                         <filename>firefox-debugsource-128.11.0-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1637</id>
          <title>An update for coreutils is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-06-13"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-5278" id="CVE-2025-5278" title="CVE-2025-5278" type="cve"></reference>
          </references>
          <description>A flaw was found in GNU Coreutils. The sort utility&#39;s begfield() function is vulnerable to a heap buffer under-read. The program may access memory outside the allocated buffer if a user runs a crafted command using the traditional key format. A malicious input could lead to a crash or leak sensitive data.(CVE-2025-5278)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="coreutils" release="20.oe2203sp4" version="9.0">
                         <filename>coreutils-9.0-20.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="coreutils-debuginfo" release="20.oe2203sp4" version="9.0">
                         <filename>coreutils-debuginfo-9.0-20.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="coreutils-debugsource" release="20.oe2203sp4" version="9.0">
                         <filename>coreutils-debugsource-9.0-20.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="coreutils-help" release="20.oe2203sp4" version="9.0">
                         <filename>coreutils-help-9.0-20.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="coreutils" release="20.oe2203sp4" version="9.0">
                         <filename>coreutils-9.0-20.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="coreutils-debuginfo" release="20.oe2203sp4" version="9.0">
                         <filename>coreutils-debuginfo-9.0-20.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="coreutils-debugsource" release="20.oe2203sp4" version="9.0">
                         <filename>coreutils-debugsource-9.0-20.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1638</id>
          <title>An update for taglib is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2025-06-13"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-47466" id="CVE-2023-47466" title="CVE-2023-47466" type="cve"></reference>
          </references>
          <description>TagLib before 2.0 allows a segmentation violation and application crash during tag writing via a crafted WAV file in which an id3 chunk is the only valid chunk.(CVE-2023-47466)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="taglib" release="13.oe2203sp4" version="1.11.1">
                         <filename>taglib-1.11.1-13.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="taglib-debuginfo" release="13.oe2203sp4" version="1.11.1">
                         <filename>taglib-debuginfo-1.11.1-13.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="taglib-debugsource" release="13.oe2203sp4" version="1.11.1">
                         <filename>taglib-debugsource-1.11.1-13.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="taglib-devel" release="13.oe2203sp4" version="1.11.1">
                         <filename>taglib-devel-1.11.1-13.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="taglib-help" release="13.oe2203sp4" version="1.11.1">
                         <filename>taglib-help-1.11.1-13.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="taglib" release="13.oe2203sp4" version="1.11.1">
                         <filename>taglib-1.11.1-13.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="taglib-debuginfo" release="13.oe2203sp4" version="1.11.1">
                         <filename>taglib-debuginfo-1.11.1-13.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="taglib-debugsource" release="13.oe2203sp4" version="1.11.1">
                         <filename>taglib-debugsource-1.11.1-13.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="taglib-devel" release="13.oe2203sp4" version="1.11.1">
                         <filename>taglib-devel-1.11.1-13.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1639</id>
          <title>An update for yasm is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-06-13"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-22653" id="CVE-2024-22653" title="CVE-2024-22653" type="cve"></reference>
          </references>
          <description>yasm commit 9defefae was discovered to contain a NULL pointer dereference via the yasm_section_bcs_append function at section.c.(CVE-2024-22653)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="yasm" release="14.oe2203sp4" version="1.3.0">
                         <filename>yasm-1.3.0-14.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="yasm-debuginfo" release="14.oe2203sp4" version="1.3.0">
                         <filename>yasm-debuginfo-1.3.0-14.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="yasm-debugsource" release="14.oe2203sp4" version="1.3.0">
                         <filename>yasm-debugsource-1.3.0-14.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="yasm-devel" release="14.oe2203sp4" version="1.3.0">
                         <filename>yasm-devel-1.3.0-14.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="yasm-help" release="14.oe2203sp4" version="1.3.0">
                         <filename>yasm-help-1.3.0-14.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="yasm" release="14.oe2203sp4" version="1.3.0">
                         <filename>yasm-1.3.0-14.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="yasm-debuginfo" release="14.oe2203sp4" version="1.3.0">
                         <filename>yasm-debuginfo-1.3.0-14.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="yasm-debugsource" release="14.oe2203sp4" version="1.3.0">
                         <filename>yasm-debugsource-1.3.0-14.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="yasm-devel" release="14.oe2203sp4" version="1.3.0">
                         <filename>yasm-devel-1.3.0-14.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1640</id>
          <title>An update for ruby is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-06-13"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-43857" id="CVE-2025-43857" title="CVE-2025-43857" type="cve"></reference>
          </references>
          <description>Net::IMAP implements Internet Message Access Protocol (IMAP) client functionality in Ruby. Prior to versions 0.5.7, 0.4.20, 0.3.9, and 0.2.5, there is a possibility for denial of service by memory exhaustion when net-imap reads server responses. At any time while the client is connected, a malicious server can send can send a &#34;literal&#34; byte count, which is automatically read by the client&#39;s receiver thread. The response reader immediately allocates memory for the number of bytes indicated by the server response. This should not be an issue when securely connecting to trusted IMAP servers that are well-behaved. It can affect insecure connections and buggy, untrusted, or compromised servers (for example, connecting to a user supplied hostname). This issue has been patched in versions 0.5.7, 0.4.20, 0.3.9, and 0.2.5.(CVE-2025-43857)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="ruby" release="143.oe2203sp4" version="3.0.3">
                         <filename>ruby-3.0.3-143.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ruby-debuginfo" release="143.oe2203sp4" version="3.0.3">
                         <filename>ruby-debuginfo-3.0.3-143.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ruby-debugsource" release="143.oe2203sp4" version="3.0.3">
                         <filename>ruby-debugsource-3.0.3-143.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ruby-devel" release="143.oe2203sp4" version="3.0.3">
                         <filename>ruby-devel-3.0.3-143.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-bigdecimal" release="143.oe2203sp4" version="3.0.0">
                         <filename>rubygem-bigdecimal-3.0.0-143.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-io-console" release="143.oe2203sp4" version="0.5.7">
                         <filename>rubygem-io-console-0.5.7-143.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-json" release="143.oe2203sp4" version="2.5.1">
                         <filename>rubygem-json-2.5.1-143.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-openssl" release="143.oe2203sp4" version="2.2.1">
                         <filename>rubygem-openssl-2.2.1-143.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-psych" release="143.oe2203sp4" version="3.3.2">
                         <filename>rubygem-psych-3.3.2-143.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="ruby-help" release="143.oe2203sp4" version="3.0.3">
                         <filename>ruby-help-3.0.3-143.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="ruby-irb" release="143.oe2203sp4" version="3.0.3">
                         <filename>ruby-irb-3.0.3-143.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-bundler" release="143.oe2203sp4" version="2.2.32">
                         <filename>rubygem-bundler-2.2.32-143.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-did_you_mean" release="143.oe2203sp4" version="1.5.0">
                         <filename>rubygem-did_you_mean-1.5.0-143.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-minitest" release="143.oe2203sp4" version="5.14.2">
                         <filename>rubygem-minitest-5.14.2-143.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rake" release="143.oe2203sp4" version="13.0.3">
                         <filename>rubygem-rake-13.0.3-143.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rbs" release="143.oe2203sp4" version="1.4.0">
                         <filename>rubygem-rbs-1.4.0-143.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rdoc" release="143.oe2203sp4" version="6.3.3">
                         <filename>rubygem-rdoc-6.3.3-143.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rexml" release="143.oe2203sp4" version="3.2.5">
                         <filename>rubygem-rexml-3.2.5-143.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rss" release="143.oe2203sp4" version="0.2.9">
                         <filename>rubygem-rss-0.2.9-143.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-test-unit" release="143.oe2203sp4" version="3.3.7">
                         <filename>rubygem-test-unit-3.3.7-143.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-typeprof" release="143.oe2203sp4" version="0.15.2">
                         <filename>rubygem-typeprof-0.15.2-143.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygems" release="143.oe2203sp4" version="3.2.32">
                         <filename>rubygems-3.2.32-143.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygems-devel" release="143.oe2203sp4" version="3.2.32">
                         <filename>rubygems-devel-3.2.32-143.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby" release="143.oe2203sp4" version="3.0.3">
                         <filename>ruby-3.0.3-143.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby-debuginfo" release="143.oe2203sp4" version="3.0.3">
                         <filename>ruby-debuginfo-3.0.3-143.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby-debugsource" release="143.oe2203sp4" version="3.0.3">
                         <filename>ruby-debugsource-3.0.3-143.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby-devel" release="143.oe2203sp4" version="3.0.3">
                         <filename>ruby-devel-3.0.3-143.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-bigdecimal" release="143.oe2203sp4" version="3.0.0">
                         <filename>rubygem-bigdecimal-3.0.0-143.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-io-console" release="143.oe2203sp4" version="0.5.7">
                         <filename>rubygem-io-console-0.5.7-143.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-json" release="143.oe2203sp4" version="2.5.1">
                         <filename>rubygem-json-2.5.1-143.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-openssl" release="143.oe2203sp4" version="2.2.1">
                         <filename>rubygem-openssl-2.2.1-143.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-psych" release="143.oe2203sp4" version="3.3.2">
                         <filename>rubygem-psych-3.3.2-143.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1641</id>
          <title>An update for tomcat is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-06-13"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-46701" id="CVE-2025-46701" title="CVE-2025-46701" type="cve"></reference>
          </references>
          <description>A vulnerability was found in Apache Tomcat up to 9.0.104/10.1.40/11.0.6 (Application Server Software) and classified as critical.Using CWE to declare the problem leads to CWE-178. The product does not properly account for differences in case sensitivity when accessing or determining the properties of a resource, leading to inconsistent results.Impacted is integrity.Upgrading to version 9.0.105, 10.1.41 or 11.0.7 eliminates this vulnerability.(CVE-2025-46701)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="noarch" name="tomcat" release="3.oe2203sp4" version="9.0.100">
                         <filename>tomcat-9.0.100-3.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="tomcat-help" release="3.oe2203sp4" version="9.0.100">
                         <filename>tomcat-help-9.0.100-3.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="tomcat-jsvc" release="3.oe2203sp4" version="9.0.100">
                         <filename>tomcat-jsvc-9.0.100-3.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1644</id>
          <title>An update for tomcat is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-06-20"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-48988" id="CVE-2025-48988" title="CVE-2025-48988" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-49125" id="CVE-2025-49125" title="CVE-2025-49125" type="cve"></reference>
          </references>
          <description>Allocation of Resources Without Limits or Throttling vulnerability in Apache Tomcat.This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.7, from 10.1.0-M1 through 10.1.41, from 9.0.0.M1 through 9.0.105.Users are recommended to upgrade to version 11.0.8, 10.1.42 or 9.0.106, which fix the issue.(CVE-2025-48988)Authentication Bypass Using an Alternate Path or Channel vulnerability in Apache Tomcat.  When using PreResources or PostResources mounted other than at the root of the web application, it was possible to access those resources via an unexpected path. That path was likely not to be protected by the same security constraints as the expected path, allowing those security constraints to be bypassed.This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.7, from 10.1.0-M1 through 10.1.41, from 9.0.0.M1 through 9.0.105.Users are recommended to upgrade to version 11.0.8, 10.1.42 or 9.0.106, which fix the issue.(CVE-2025-49125)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="tomcat" release="4.oe2203sp4" version="9.0.100">
                         <filename>tomcat-9.0.100-4.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="tomcat-help" release="4.oe2203sp4" version="9.0.100">
                         <filename>tomcat-help-9.0.100-4.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="tomcat-jsvc" release="4.oe2203sp4" version="9.0.100">
                         <filename>tomcat-jsvc-9.0.100-4.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1645</id>
          <title>An update for nodejs-brace-expansion is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2025-06-20"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-5889" id="CVE-2025-5889" title="CVE-2025-5889" type="cve"></reference>
          </references>
          <description>A vulnerability was found in juliangruber brace-expansion up to 1.1.11/2.0.1/3.0.0/4.0.0. It has been rated as problematic. Affected by this issue is the function expand of the file index.js. The manipulation leads to inefficient regular expression complexity. The attack may be launched remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. Upgrading to version 1.1.12, 2.0.2, 3.0.1 and 4.0.1 is able to address this issue. The name of the patch is a5b98a4f30d7813266b221435e1eaaf25a1b0ac5. It is recommended to upgrade the affected component.(CVE-2025-5889)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="nodejs-brace-expansion" release="2.oe2203sp4" version="1.1.11">
                         <filename>nodejs-brace-expansion-1.1.11-2.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1646</id>
          <title>An update for perl-File-Find-Rule is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-06-20"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2011-10007" id="CVE-2011-10007" title="CVE-2011-10007" type="cve"></reference>
          </references>
          <description>File::Find::Rule through 0.34 for Perl is vulnerable to Arbitrary Code Execution when `grep()` encounters a crafted filename.A file handle is opened with the 2 argument form of `open()` allowing an attacker controlled filename to provide the MODE parameter to `open()`, turning the filename into a command to be executed.Example:$ mkdir /tmp/poc; echo &gt; &#34;/tmp/poc/|id&#34;$ perl -MFile::Find::Rule \    -E &#39;File::Find::Rule-&gt;grep(&#34;foo&#34;)-&gt;in(&#34;/tmp/poc&#34;)&#39;uid=1000(user) gid=1000(user) groups=1000(user),100(users)(CVE-2011-10007)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="perl-File-Find-Rule" release="3.oe2203sp4" version="0.34">
                         <filename>perl-File-Find-Rule-0.34-3.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="perl-File-Find-Rule-help" release="3.oe2203sp4" version="0.34">
                         <filename>perl-File-Find-Rule-help-0.34-3.oe2203sp4.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1649</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-06-20"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21546" id="CVE-2022-21546" title="CVE-2022-21546" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-53039" id="CVE-2023-53039" title="CVE-2023-53039" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-58083" id="CVE-2024-58083" title="CVE-2024-58083" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-21704" id="CVE-2025-21704" title="CVE-2025-21704" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:scsi: target: Fix WRITE_SAME No Data Buffer crashIn newer version of the SBC specs, we have a NDOB bit that indicates thereis no data buffer that gets written out. If this bit is set using commandslike &#34;sg_write_same --ndob&#34; we will crash in target_core_iblock/file&#39;sexecute_write_same handlers when we go to access the se_cmd-&gt;t_data_sgbecause its NULL.This patch adds a check for the NDOB bit in the common WRITE SAME codebecause we don&#39;t support it. And, it adds a check for zero SG elements ineach handler in case the initiator tries to send a normal WRITE SAME withno data buffer.(CVE-2022-21546)In the Linux kernel, the following vulnerability has been resolved:HID: intel-ish-hid: ipc: Fix potential use-after-free in work functionWhen a reset notify IPC message is received, the ISR schedules a workfunction and passes the ISHTP device to it via a global pointerishtp_dev. If ish_probe() fails, the devm-managed device resourcesincluding ishtp_dev are freed, but the work is not cancelled, causing ause-after-free when the work function tries to access ishtp_dev. Usedevm_work_autocancel() instead, so that the work is automaticallycancelled if probe fails.(CVE-2023-53039)In the Linux kernel, the following vulnerability has been resolved:KVM: Explicitly verify target vCPU is online in kvm_get_vcpu()Explicitly verify the target vCPU is fully online _prior_ to clamping theindex in kvm_get_vcpu().  If the index is &#34;bad&#34;, the nospec clamping willgenerate &#39;0&#39;, i.e. KVM will return vCPU0 instead of NULL.In practice, the bug is unlikely to cause problems, as it will only comeinto play if userspace or the guest is buggy or misbehaving, e.g. KVM maysend interrupts to vCPU0 instead of dropping them on the floor.However, returning vCPU0 when it shouldn&#39;t exist per online_vcpus isproblematic now that KVM uses an xarray for the vCPUs array, as KVM needsto insert into the xarray before publishing the vCPU to userspace (seecommit c5b077549136 (&#34;KVM: Convert the kvm-&gt;vcpus array to a xarray&#34;)),i.e. before vCPU creation is guaranteed to succeed.As a result, incorrectly providing access to vCPU0 will trigger ause-after-free if vCPU0 is dereferenced and kvm_vm_ioctl_create_vcpu()bails out of vCPU creation due to an error and frees vCPU0.  Commitafb2acb2e3a3 (&#34;KVM: Fix vcpu_array[0] races&#34;) papered over that issue, butin doing so introduced an unsolvable teardown conundrum.  Preventingaccesses to vCPU0 before it&#39;s fully online will allow reverting commitafb2acb2e3a3, without re-introducing the vcpu_array[0] UAF race.(CVE-2024-58083)In the Linux kernel, the following vulnerability has been resolved:usb: cdc-acm: Check control transfer buffer size before accessIf the first fragment is shorter than struct usb_cdc_notification, we can&#39;tcalculate an expected_size. Log an error and discard the notificationinstead of reading lengths from memory outside the received data, which canlead to memory corruption when the expected_size decreases betweenfragments, causing `expected_size - acm-&gt;nb_index` to wrap.This issue has been present since the beginning of git history; however,it only leads to memory corruption since commit ea2583529cd1(&#34;cdc-acm: reassemble fragmented notifications&#34;).A mitigating factor is that acm_ctrl_irq() can only execute after userspacehas opened /dev/ttyACM*; but if ModemManager is running, ModemManager willdo that automatically depending on the USB device&#39;s vendor/product IDs andits other interfaces.(CVE-2025-21704)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="bpftool" release="268.0.0.171.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-268.0.0.171.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="268.0.0.171.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-268.0.0.171.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="268.0.0.171.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-268.0.0.171.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="268.0.0.171.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-268.0.0.171.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="268.0.0.171.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-268.0.0.171.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="268.0.0.171.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-268.0.0.171.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="268.0.0.171.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-268.0.0.171.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="268.0.0.171.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-268.0.0.171.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="268.0.0.171.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-268.0.0.171.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="268.0.0.171.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-268.0.0.171.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="268.0.0.171.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-268.0.0.171.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="268.0.0.171.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-268.0.0.171.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="268.0.0.171.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-268.0.0.171.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="268.0.0.171.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-268.0.0.171.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="268.0.0.171.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-268.0.0.171.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="268.0.0.171.oe2203sp4" version="5.10.0">
                         <filename>bpftool-5.10.0-268.0.0.171.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="268.0.0.171.oe2203sp4" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-268.0.0.171.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="268.0.0.171.oe2203sp4" version="5.10.0">
                         <filename>kernel-5.10.0-268.0.0.171.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="268.0.0.171.oe2203sp4" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-268.0.0.171.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="268.0.0.171.oe2203sp4" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-268.0.0.171.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="268.0.0.171.oe2203sp4" version="5.10.0">
                         <filename>kernel-devel-5.10.0-268.0.0.171.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="268.0.0.171.oe2203sp4" version="5.10.0">
                         <filename>kernel-headers-5.10.0-268.0.0.171.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="268.0.0.171.oe2203sp4" version="5.10.0">
                         <filename>kernel-source-5.10.0-268.0.0.171.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="268.0.0.171.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-5.10.0-268.0.0.171.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="268.0.0.171.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-268.0.0.171.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="268.0.0.171.oe2203sp4" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-268.0.0.171.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="268.0.0.171.oe2203sp4" version="5.10.0">
                         <filename>perf-5.10.0-268.0.0.171.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="268.0.0.171.oe2203sp4" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-268.0.0.171.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="268.0.0.171.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-5.10.0-268.0.0.171.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="268.0.0.171.oe2203sp4" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-268.0.0.171.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1653</id>
          <title>An update for firefox is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2025-06-20"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-5283" id="CVE-2025-5283" title="CVE-2025-5283" type="cve"></reference>
          </references>
          <description>Use after free in libvpx in Google Chrome prior to 137.0.7151.55 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: Medium)(CVE-2025-5283)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="firefox" release="1.oe2203sp4" version="128.11.0">
                         <filename>firefox-128.11.0-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="firefox-debuginfo" release="1.oe2203sp4" version="128.11.0">
                         <filename>firefox-debuginfo-128.11.0-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="firefox-debugsource" release="1.oe2203sp4" version="128.11.0">
                         <filename>firefox-debugsource-128.11.0-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox" release="1.oe2203sp4" version="128.11.0">
                         <filename>firefox-128.11.0-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox-debuginfo" release="1.oe2203sp4" version="128.11.0">
                         <filename>firefox-debuginfo-128.11.0-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox-debugsource" release="1.oe2203sp4" version="128.11.0">
                         <filename>firefox-debugsource-128.11.0-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1654</id>
          <title>An update for qt5-qtbase is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-06-20"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-5455" id="CVE-2025-5455" title="CVE-2025-5455" type="cve"></reference>
          </references>
          <description>An issue was found in the private API function qDecodeDataUrl() in QtCore, which is used in QTextDocument and QNetworkReply, and, potentially, in user code.If the function was called with malformed data, for example, an URL thatcontained a &#34;charset&#34; parameter that lacked a value (such as&#34;data:charset,&#34;), and Qt was built with assertions enabled, then it would hit an assertion, resulting in a denial of service(abort).This impacts Qt up to 5.15.18, 6.0.0-&gt;6.5.8, 6.6.0-&gt;6.8.3 and 6.9.0. This has been fixed in 5.15.19, 6.5.9, 6.8.4 and 6.9.1.(CVE-2025-5455)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="qt5-qtbase" release="18.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtbase-5.15.2-18.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-debuginfo" release="18.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtbase-debuginfo-5.15.2-18.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-debugsource" release="18.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtbase-debugsource-5.15.2-18.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-devel" release="18.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtbase-devel-5.15.2-18.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-examples" release="18.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtbase-examples-5.15.2-18.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-gui" release="18.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtbase-gui-5.15.2-18.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-mysql" release="18.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtbase-mysql-5.15.2-18.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-odbc" release="18.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtbase-odbc-5.15.2-18.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-postgresql" release="18.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtbase-postgresql-5.15.2-18.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-private-devel" release="18.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtbase-private-devel-5.15.2-18.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-static" release="18.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtbase-static-5.15.2-18.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="qt5-qtbase-common" release="18.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtbase-common-5.15.2-18.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase" release="18.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtbase-5.15.2-18.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-debuginfo" release="18.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtbase-debuginfo-5.15.2-18.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-debugsource" release="18.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtbase-debugsource-5.15.2-18.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-devel" release="18.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtbase-devel-5.15.2-18.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-examples" release="18.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtbase-examples-5.15.2-18.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-gui" release="18.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtbase-gui-5.15.2-18.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-mysql" release="18.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtbase-mysql-5.15.2-18.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-odbc" release="18.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtbase-odbc-5.15.2-18.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-postgresql" release="18.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtbase-postgresql-5.15.2-18.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-private-devel" release="18.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtbase-private-devel-5.15.2-18.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-static" release="18.oe2203sp4" version="5.15.2">
                         <filename>qt5-qtbase-static-5.15.2-18.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1658</id>
          <title>An update for libarchive is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2025-06-20"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-5914" id="CVE-2025-5914" title="CVE-2025-5914" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-5916" id="CVE-2025-5916" title="CVE-2025-5916" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-5917" id="CVE-2025-5917" title="CVE-2025-5917" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-5918" id="CVE-2025-5918" title="CVE-2025-5918" type="cve"></reference>
          </references>
          <description>A vulnerability was found in libarchive up to 3.7.x (File Compression Software). It has been classified as critical.CWE is classifying the issue as CWE-415. The product calls free() twice on the same memory address, potentially leading to modification of unexpected memory locations.This is going to have an impact on confidentiality, integrity, and availability.Upgrading to version 3.8.0 eliminates this vulnerability.(CVE-2025-5914)A vulnerability has been identified in the libarchive library. This flaw involves an integer overflow that can be triggered when processing a Web Archive (WARC) file that claims to have more than INT64_MAX - 4 content bytes. An attacker could craft a malicious WARC archive to induce this overflow, potentially leading to unpredictable program behavior, memory corruption, or a denial-of-service condition within applications that process such archives using libarchive.(CVE-2025-5916)A vulnerability has been identified in the libarchive library. This flaw involves an &#39;off-by-one&#39; miscalculation when handling prefixes and suffixes for file names. This can lead to a 1-byte write overflow. While seemingly small, such an overflow can corrupt adjacent memory, leading to unpredictable program behavior, crashes, or in specific circumstances, could be leveraged as a building block for more sophisticated exploitation.(CVE-2025-5917)A vulnerability has been identified in the libarchive library. This flaw can be triggered when file streams are piped into bsdtar, potentially allowing for reading past the end of the file. This out-of-bounds read can lead to unintended consequences, including unpredictable program behavior, memory corruption, or a denial-of-service condition.(CVE-2025-5918)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="bsdcat" release="9.oe2203sp4" version="3.5.2">
                         <filename>bsdcat-3.5.2-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bsdcpio" release="9.oe2203sp4" version="3.5.2">
                         <filename>bsdcpio-3.5.2-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bsdtar" release="9.oe2203sp4" version="3.5.2">
                         <filename>bsdtar-3.5.2-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libarchive" release="9.oe2203sp4" version="3.5.2">
                         <filename>libarchive-3.5.2-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libarchive-debuginfo" release="9.oe2203sp4" version="3.5.2">
                         <filename>libarchive-debuginfo-3.5.2-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libarchive-debugsource" release="9.oe2203sp4" version="3.5.2">
                         <filename>libarchive-debugsource-3.5.2-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libarchive-devel" release="9.oe2203sp4" version="3.5.2">
                         <filename>libarchive-devel-3.5.2-9.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="libarchive-help" release="9.oe2203sp4" version="3.5.2">
                         <filename>libarchive-help-3.5.2-9.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bsdcat" release="9.oe2203sp4" version="3.5.2">
                         <filename>bsdcat-3.5.2-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bsdcpio" release="9.oe2203sp4" version="3.5.2">
                         <filename>bsdcpio-3.5.2-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bsdtar" release="9.oe2203sp4" version="3.5.2">
                         <filename>bsdtar-3.5.2-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libarchive" release="9.oe2203sp4" version="3.5.2">
                         <filename>libarchive-3.5.2-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libarchive-debuginfo" release="9.oe2203sp4" version="3.5.2">
                         <filename>libarchive-debuginfo-3.5.2-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libarchive-debugsource" release="9.oe2203sp4" version="3.5.2">
                         <filename>libarchive-debugsource-3.5.2-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libarchive-devel" release="9.oe2203sp4" version="3.5.2">
                         <filename>libarchive-devel-3.5.2-9.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2025-1663</id>
          <title>An update for wireshark is now available for openEuler-22.03-LTS-SP4</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2025-06-20"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-11596" id="CVE-2024-11596" title="CVE-2024-11596" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2025-5601" id="CVE-2025-5601" title="CVE-2025-5601" type="cve"></reference>
          </references>
          <description>A vulnerability, which was classified as problematic, has been found in Wireshark up to 4.2.8/4.4.1 (Packet Analyzer Software).Using CWE to declare the problem leads to CWE-126. The product reads from a buffer using buffer access mechanisms such as indexes or pointers that reference memory locations after the targeted buffer.Impacted is availability.Upgrading to version 4.2.9 or 4.4.2 eliminates this vulnerability.(CVE-2024-11596)Column handling crashes in Wireshark 4.4.0 to 4.4.6 and 4.2.0 to 4.2.12 allows denial of service via packet injection or crafted capture file(CVE-2025-5601)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="wireshark" release="1.oe2203sp4" version="4.4.7">
                         <filename>wireshark-4.4.7-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="wireshark-debuginfo" release="1.oe2203sp4" version="4.4.7">
                         <filename>wireshark-debuginfo-4.4.7-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="wireshark-debugsource" release="1.oe2203sp4" version="4.4.7">
                         <filename>wireshark-debugsource-4.4.7-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="wireshark-devel" release="1.oe2203sp4" version="4.4.7">
                         <filename>wireshark-devel-4.4.7-1.oe2203sp4.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="wireshark-help" release="1.oe2203sp4" version="4.4.7">
                         <filename>wireshark-help-4.4.7-1.oe2203sp4.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="wireshark" release="1.oe2203sp4" version="4.4.7">
                         <filename>wireshark-4.4.7-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="wireshark-debuginfo" release="1.oe2203sp4" version="4.4.7">
                         <filename>wireshark-debuginfo-4.4.7-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="wireshark-debugsource" release="1.oe2203sp4" version="4.4.7">
                         <filename>wireshark-debugsource-4.4.7-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="wireshark-devel" release="1.oe2203sp4" version="4.4.7">
                         <filename>wireshark-devel-4.4.7-1.oe2203sp4.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
</updates>