334 lines
19 KiB
XML
334 lines
19 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<cvrfdoc xmlns="http://www.icasi.org/CVRF/schema/cvrf/1.1" xmlns:cvrf="http://www.icasi.org/CVRF/schema/cvrf/1.1">
|
|
<DocumentTitle xml:lang="en">An update for kernel is now available for openEuler-24.03-LTS</DocumentTitle>
|
|
<DocumentType>Security Advisory</DocumentType>
|
|
<DocumentPublisher Type="Vendor">
|
|
<ContactDetails>openeuler-security@openeuler.org</ContactDetails>
|
|
<IssuingAuthority>openEuler security committee</IssuingAuthority>
|
|
</DocumentPublisher>
|
|
<DocumentTracking>
|
|
<Identification>
|
|
<ID>openEuler-SA-2024-1794</ID>
|
|
</Identification>
|
|
<Status>Final</Status>
|
|
<Version>1.0</Version>
|
|
<RevisionHistory>
|
|
<Revision>
|
|
<Number>1.0</Number>
|
|
<Date>2024-07-05</Date>
|
|
<Description>Initial</Description>
|
|
</Revision>
|
|
</RevisionHistory>
|
|
<InitialReleaseDate>2024-07-05</InitialReleaseDate>
|
|
<CurrentReleaseDate>2024-07-05</CurrentReleaseDate>
|
|
<Generator>
|
|
<Engine>openEuler SA Tool V1.0</Engine>
|
|
<Date>2024-07-05</Date>
|
|
</Generator>
|
|
</DocumentTracking>
|
|
<DocumentNotes>
|
|
<Note Title="Synopsis" Type="General" Ordinal="1" xml:lang="en">kernel security update</Note>
|
|
<Note Title="Summary" Type="General" Ordinal="2" xml:lang="en">An update for kernel is now available for openEuler-24.03-LTS</Note>
|
|
<Note Title="Description" Type="General" Ordinal="3" xml:lang="en">The Linux Kernel, the operating system core itself.
|
|
|
|
Security Fix(es):
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
clk: sunxi-ng: h6: Reparent CPUX during PLL CPUX rate change
|
|
|
|
While PLL CPUX clock rate change when CPU is running from it works in
|
|
vast majority of cases, now and then it causes instability. This leads
|
|
to system crashes and other undefined behaviour. After a lot of testing
|
|
(30+ hours) while also doing a lot of frequency switches, we can't
|
|
observe any instability issues anymore when doing reparenting to stable
|
|
clock like 24 MHz oscillator.(CVE-2023-52882)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
usb: gadget: uvc: use correct buffer size when parsing configfs lists
|
|
|
|
This commit fixes uvc gadget support on 32-bit platforms.
|
|
|
|
Commit 0df28607c5cb ("usb: gadget: uvc: Generalise helper functions for
|
|
reuse") introduced a helper function __uvcg_iter_item_entries() to aid
|
|
with parsing lists of items on configfs attributes stores. This function
|
|
is a generalization of another very similar function, which used a
|
|
stack-allocated temporary buffer of fixed size for each item in the list
|
|
and used the sizeof() operator to check for potential buffer overruns.
|
|
The new function was changed to allocate the now variably sized temp
|
|
buffer on heap, but wasn't properly updated to also check for max buffer
|
|
size using the computed size instead of sizeof() operator.
|
|
|
|
As a result, the maximum item size was 7 (plus null terminator) on
|
|
64-bit platforms, and 3 on 32-bit ones. While 7 is accidentally just
|
|
barely enough, 3 is definitely too small for some of UVC configfs
|
|
attributes. For example, dwFrameInteval, specified in 100ns units,
|
|
usually has 6-digit item values, e.g. 166666 for 60fps.(CVE-2024-36895)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
firewire: ohci: mask bus reset interrupts between ISR and bottom half
|
|
|
|
In the FireWire OHCI interrupt handler, if a bus reset interrupt has
|
|
occurred, mask bus reset interrupts until bus_reset_work has serviced and
|
|
cleared the interrupt.
|
|
|
|
Normally, we always leave bus reset interrupts masked. We infer the bus
|
|
reset from the self-ID interrupt that happens shortly thereafter. A
|
|
scenario where we unmask bus reset interrupts was introduced in 2008 in
|
|
a007bb857e0b26f5d8b73c2ff90782d9c0972620: If
|
|
OHCI_PARAM_DEBUG_BUSRESETS (8) is set in the debug parameter bitmask, we
|
|
will unmask bus reset interrupts so we can log them.
|
|
|
|
irq_handler logs the bus reset interrupt. However, we can't clear the bus
|
|
reset event flag in irq_handler, because we won't service the event until
|
|
later. irq_handler exits with the event flag still set. If the
|
|
corresponding interrupt is still unmasked, the first bus reset will
|
|
usually freeze the system due to irq_handler being called again each
|
|
time it exits. This freeze can be reproduced by loading firewire_ohci
|
|
with "modprobe firewire_ohci debug=-1" (to enable all debugging output).
|
|
Apparently there are also some cases where bus_reset_work will get called
|
|
soon enough to clear the event, and operation will continue normally.
|
|
|
|
This freeze was first reported a few months after a007bb85 was committed,
|
|
but until now it was never fixed. The debug level could safely be set
|
|
to -1 through sysfs after the module was loaded, but this would be
|
|
ineffectual in logging bus reset interrupts since they were only
|
|
unmasked during initialization.
|
|
|
|
irq_handler will now leave the event flag set but mask bus reset
|
|
interrupts, so irq_handler won't be called again and there will be no
|
|
freeze. If OHCI_PARAM_DEBUG_BUSRESETS is enabled, bus_reset_work will
|
|
unmask the interrupt after servicing the event, so future interrupts
|
|
will be caught as desired.
|
|
|
|
As a side effect to this change, OHCI_PARAM_DEBUG_BUSRESETS can now be
|
|
enabled through sysfs in addition to during initial module loading.
|
|
However, when enabled through sysfs, logging of bus reset interrupts will
|
|
be effective only starting with the second bus reset, after
|
|
bus_reset_work has executed.(CVE-2024-36950)</Note>
|
|
<Note Title="Topic" Type="General" Ordinal="4" xml:lang="en">An update for kernel is now available for openEuler-24.03-LTS.
|
|
|
|
openEuler Security has rated this update as having a security impact of medium. A Common Vunlnerability Scoring System(CVSS)base score,which gives a detailed severity rating, is available for each vulnerability from the CVElink(s) in the References section.</Note>
|
|
<Note Title="Severity" Type="General" Ordinal="5" xml:lang="en">Medium</Note>
|
|
<Note Title="Affected Component" Type="General" Ordinal="6" xml:lang="en">kernel</Note>
|
|
</DocumentNotes>
|
|
<DocumentReferences>
|
|
<Reference Type="Self">
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1794</URL>
|
|
</Reference>
|
|
<Reference Type="openEuler CVE">
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2023-52882</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-36895</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-36950</URL>
|
|
</Reference>
|
|
<Reference Type="Other">
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52882</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36895</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36950</URL>
|
|
</Reference>
|
|
</DocumentReferences>
|
|
<ProductTree xmlns="http://www.icasi.org/CVRF/schema/prod/1.1">
|
|
<Branch Type="Product Name" Name="openEuler">
|
|
<FullProductName ProductID="openEuler-24.03-LTS" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">openEuler-24.03-LTS</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="aarch64">
|
|
<FullProductName ProductID="bpftool-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">bpftool-6.6.0-31.0.0.39.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-debuginfo-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">bpftool-debuginfo-6.6.0-31.0.0.39.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-6.6.0-31.0.0.39.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-debuginfo-6.6.0-31.0.0.39.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-debugsource-6.6.0-31.0.0.39.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-devel-6.6.0-31.0.0.39.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-headers-6.6.0-31.0.0.39.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-source-6.6.0-31.0.0.39.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-tools-6.6.0-31.0.0.39.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-tools-debuginfo-6.6.0-31.0.0.39.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-tools-devel-6.6.0-31.0.0.39.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">perf-6.6.0-31.0.0.39.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">perf-debuginfo-6.6.0-31.0.0.39.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">python3-perf-6.6.0-31.0.0.39.oe2403.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">python3-perf-debuginfo-6.6.0-31.0.0.39.oe2403.aarch64.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="x86_64">
|
|
<FullProductName ProductID="bpftool-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">bpftool-6.6.0-31.0.0.39.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-debuginfo-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">bpftool-debuginfo-6.6.0-31.0.0.39.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-6.6.0-31.0.0.39.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-debuginfo-6.6.0-31.0.0.39.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-debugsource-6.6.0-31.0.0.39.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-devel-6.6.0-31.0.0.39.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-headers-6.6.0-31.0.0.39.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-source-6.6.0-31.0.0.39.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-tools-6.6.0-31.0.0.39.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-tools-debuginfo-6.6.0-31.0.0.39.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-tools-devel-6.6.0-31.0.0.39.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">perf-6.6.0-31.0.0.39.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">perf-debuginfo-6.6.0-31.0.0.39.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">python3-perf-6.6.0-31.0.0.39.oe2403.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">python3-perf-debuginfo-6.6.0-31.0.0.39.oe2403.x86_64.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="src">
|
|
<FullProductName ProductID="kernel-6.6.0-31.0.0.39" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-6.6.0-31.0.0.39.oe2403.src.rpm</FullProductName>
|
|
</Branch>
|
|
</ProductTree>
|
|
<Vulnerability Ordinal="1" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
clk: sunxi-ng: h6: Reparent CPUX during PLL CPUX rate change
|
|
|
|
While PLL CPUX clock rate change when CPU is running from it works in
|
|
vast majority of cases, now and then it causes instability. This leads
|
|
to system crashes and other undefined behaviour. After a lot of testing
|
|
(30+ hours) while also doing a lot of frequency switches, we can't
|
|
observe any instability issues anymore when doing reparenting to stable
|
|
clock like 24 MHz oscillator.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-05</ReleaseDate>
|
|
<CVE>CVE-2023-52882</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-05</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1794</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="2" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
usb: gadget: uvc: use correct buffer size when parsing configfs lists
|
|
|
|
This commit fixes uvc gadget support on 32-bit platforms.
|
|
|
|
Commit 0df28607c5cb ("usb: gadget: uvc: Generalise helper functions for
|
|
reuse") introduced a helper function __uvcg_iter_item_entries() to aid
|
|
with parsing lists of items on configfs attributes stores. This function
|
|
is a generalization of another very similar function, which used a
|
|
stack-allocated temporary buffer of fixed size for each item in the list
|
|
and used the sizeof() operator to check for potential buffer overruns.
|
|
The new function was changed to allocate the now variably sized temp
|
|
buffer on heap, but wasn't properly updated to also check for max buffer
|
|
size using the computed size instead of sizeof() operator.
|
|
|
|
As a result, the maximum item size was 7 (plus null terminator) on
|
|
64-bit platforms, and 3 on 32-bit ones. While 7 is accidentally just
|
|
barely enough, 3 is definitely too small for some of UVC configfs
|
|
attributes. For example, dwFrameInteval, specified in 100ns units,
|
|
usually has 6-digit item values, e.g. 166666 for 60fps.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-05</ReleaseDate>
|
|
<CVE>CVE-2024-36895</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>None</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>3.9</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:L</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-05</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1794</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="3" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
firewire: ohci: mask bus reset interrupts between ISR and bottom half
|
|
|
|
In the FireWire OHCI interrupt handler, if a bus reset interrupt has
|
|
occurred, mask bus reset interrupts until bus_reset_work has serviced and
|
|
cleared the interrupt.
|
|
|
|
Normally, we always leave bus reset interrupts masked. We infer the bus
|
|
reset from the self-ID interrupt that happens shortly thereafter. A
|
|
scenario where we unmask bus reset interrupts was introduced in 2008 in
|
|
a007bb857e0b26f5d8b73c2ff90782d9c0972620: If
|
|
OHCI_PARAM_DEBUG_BUSRESETS (8) is set in the debug parameter bitmask, we
|
|
will unmask bus reset interrupts so we can log them.
|
|
|
|
irq_handler logs the bus reset interrupt. However, we can't clear the bus
|
|
reset event flag in irq_handler, because we won't service the event until
|
|
later. irq_handler exits with the event flag still set. If the
|
|
corresponding interrupt is still unmasked, the first bus reset will
|
|
usually freeze the system due to irq_handler being called again each
|
|
time it exits. This freeze can be reproduced by loading firewire_ohci
|
|
with "modprobe firewire_ohci debug=-1" (to enable all debugging output).
|
|
Apparently there are also some cases where bus_reset_work will get called
|
|
soon enough to clear the event, and operation will continue normally.
|
|
|
|
This freeze was first reported a few months after a007bb85 was committed,
|
|
but until now it was never fixed. The debug level could safely be set
|
|
to -1 through sysfs after the module was loaded, but this would be
|
|
ineffectual in logging bus reset interrupts since they were only
|
|
unmasked during initialization.
|
|
|
|
irq_handler will now leave the event flag set but mask bus reset
|
|
interrupts, so irq_handler won't be called again and there will be no
|
|
freeze. If OHCI_PARAM_DEBUG_BUSRESETS is enabled, bus_reset_work will
|
|
unmask the interrupt after servicing the event, so future interrupts
|
|
will be caught as desired.
|
|
|
|
As a side effect to this change, OHCI_PARAM_DEBUG_BUSRESETS can now be
|
|
enabled through sysfs in addition to during initial module loading.
|
|
However, when enabled through sysfs, logging of bus reset interrupts will
|
|
be effective only starting with the second bus reset, after
|
|
bus_reset_work has executed.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-07-05</ReleaseDate>
|
|
<CVE>CVE-2024-36950</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-24.03-LTS</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>None</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.4</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-07-05</DATE>
|
|
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1794</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
</cvrfdoc> |