jiachao2130/cvrf2cusa
1
0
Fork 1
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
7d8412e76d
cvrf2cusa/cvrf/2024/cvrf-openEuler-SA-2024-1993.xml
Jia Chao 7d8412e76d update 0822 
Signed-off-by: Jia Chao <jiac13@chinaunicom.cn>
2024-08-22 10:38:56 +08:00

912 lines
43 KiB
XML
Raw Blame History

<?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-1993</ID>
</Identification>
<Status>Final</Status>
<Version>1.0</Version>
<RevisionHistory>
<Revision>
<Number>1.0</Number>
<Date>2024-08-16</Date>
<Description>Initial</Description>
</Revision>
</RevisionHistory>
<InitialReleaseDate>2024-08-16</InitialReleaseDate>
<CurrentReleaseDate>2024-08-16</CurrentReleaseDate>
<Generator>
<Engine>openEuler SA Tool V1.0</Engine>
<Date>2024-08-16</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:
media: mediatek: vcodec: Only free buffer VA that is not NULL
In the MediaTek vcodec driver, while mtk_vcodec_mem_free() is mostly
called only when the buffer to free exists, there are some instances
that didn&apos;t do the check and triggered warnings in practice.
We believe those checks were forgotten unintentionally. Add the checks
back to fix the warnings.(CVE-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 trying
to write a value into a field of smaller size in an output report.
Since implement() already has a warn message printed out with the
help of hid_warn() and value in question gets trimmed with:
...
value &amp;= m;
...
WARN_ON may be considered superfluous. Remove it to suppress future
syzkaller triggers.
[1]
WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 implement drivers/hid/hid-core.c:1451 [inline]
WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863
Modules linked in:
CPU: 0 PID: 5084 Comm: syz-executor424 Not tainted 6.9.0-rc7-syzkaller-00183-gcf87f46fd34d #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
RIP: 0010:implement drivers/hid/hid-core.c:1451 [inline]
RIP: 0010:hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863
...
Call Trace:
&lt;TASK&gt;
__usbhid_submit_report drivers/hid/usbhid/hid-core.c:591 [inline]
usbhid_submit_report+0x43d/0x9e0 drivers/hid/usbhid/hid-core.c:636
hiddev_ioctl+0x138b/0x1f00 drivers/hid/usbhid/hiddev.c:726
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:904 [inline]
__se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
...(CVE-2024-39509)
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: idxd: Fix possible Use-After-Free in irq_process_work_list
Use list_for_each_entry_safe() to allow iterating through the list and
deleting the entry in the iteration process. The descriptor is freed via
idxd_desc_complete() and there&apos;s a slight chance may cause issue for
the list iterator when the descriptor is reused by another thread
without it being deleted from the list.(CVE-2024-40956)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Add check for srq max_sge attribute
max_sge attribute is passed by the user, and is inserted and used
unchecked, so verify that the value doesn&apos;t exceed maximum allowed value
before using it.(CVE-2024-40990)
In the Linux kernel, the following vulnerability has been resolved:
USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor
Syzbot has identified a bug in usbcore (see the Closes: tag below)
caused by our assumption that the reserved bits in an endpoint
descriptor&apos;s bEndpointAddress field will always be 0. As a result of
the bug, the endpoint_is_duplicate() routine in config.c (and possibly
other routines as well) may believe that two descriptors are for
distinct endpoints, even though they have the same direction and
endpoint number. This can lead to confusion, including the bug
identified by syzbot (two descriptors with matching endpoint numbers
and directions, where one was interrupt and the other was bulk).
To fix the bug, we will clear the reserved bits in bEndpointAddress
when we parse the descriptor. (Note that both the USB-2.0 and USB-3.1
specs say these bits are &quot;Reserved, reset to zero&quot;.) This requires us
to make a copy of the descriptor earlier in usb_parse_endpoint() and
use the copy instead of the original when checking for duplicates.(CVE-2024-41035)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: prefer nft_chain_validate
nft_chain_validate already performs loop detection because a cycle will
result in a call stack overflow (ctx-&gt;level &gt;= NFT_JUMP_STACK_SIZE).
It also follows maps via -&gt;validate callback in nft_lookup, so there
appears no reason to iterate the maps again.
nf_tables_check_loops() and all its helper functions can be removed.
This improves ruleset load time significantly, from 23s down to 12s.
This also fixes a crash bug. Old loop detection code can result in
unbounded recursion:
BUG: TASK stack guard page was hit at ....
Oops: stack guard page: 0000 [#1] PREEMPT SMP KASAN
CPU: 4 PID: 1539 Comm: nft Not tainted 6.10.0-rc5+ #1
[..]
with a suitable ruleset during validation of register stores.
I can&apos;t see any actual reason to attempt to check for this from
nft_validate_register_store(), at this point the transaction is still in
progress, so we don&apos;t have a full picture of the rule graph.
For nf-next it might make sense to either remove it or make this depend
on table-&gt;validate_state in case we could catch an error earlier
(for improved error reporting to userspace).(CVE-2024-41042)
In the Linux kernel, the following vulnerability has been resolved:
net: ethernet: lantiq_etop: fix double free in detach
The number of the currently released descriptor is never incremented
which results in the same skb being released multiple times.(CVE-2024-41046)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix inode number range checks
Patch series &quot;nilfs2: fix potential issues related to reserved inodes&quot;.
This series fixes one use-after-free issue reported by syzbot, caused by
nilfs2&apos;s internal inode being exposed in the namespace on a corrupted
filesystem, and a couple of flaws that cause problems if the starting
number of non-reserved inodes written in the on-disk super block is
intentionally (or corruptly) changed from its default value.
This patch (of 3):
In the current implementation of nilfs2, &quot;nilfs-&gt;ns_first_ino&quot;, which
gives the first non-reserved inode number, is read from the superblock,
but its lower limit is not checked.
As a result, if a number that overlaps with the inode number range of
reserved inodes such as the root directory or metadata files is set in the
super block parameter, the inode number test macros (NILFS_MDT_INODE and
NILFS_VALID_INODE) will not function properly.
In addition, these test macros use left bit-shift calculations using with
the inode number as the shift count via the BIT macro, but the result of a
shift calculation that exceeds the bit width of an integer is undefined in
the C specification, so if &quot;ns_first_ino&quot; is set to a large value other
than the default value NILFS_USER_INO (=11), the macros may potentially
malfunction depending on the environment.
Fix these issues by checking the lower bound of &quot;nilfs-&gt;ns_first_ino&quot; and
by preventing bit shifts equal to or greater than the NILFS_USER_INO
constant in the inode number test macros.
Also, change the type of &quot;ns_first_ino&quot; from signed integer to unsigned
integer to avoid the need for type casting in comparisons such as the
lower bound check introduced this time.(CVE-2024-42105)
In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: restrict NL80211_ATTR_TXQ_QUANTUM values
syzbot is able to trigger softlockups, setting NL80211_ATTR_TXQ_QUANTUM
to 2^31.
We had a similar issue in sch_fq, fixed with commit
d9e15a273306 (&quot;pkt_sched: fq: do not accept silly TCA_FQ_QUANTUM&quot;)
watchdog: BUG: soft lockup - CPU#1 stuck for 26s! [kworker/1:0:24]
Modules linked in:
irq event stamp: 131135
hardirqs last enabled at (131134): [&lt;ffff80008ae8778c&gt;] __exit_to_kernel_mode arch/arm64/kernel/entry-common.c:85 [inline]
hardirqs last enabled at (131134): [&lt;ffff80008ae8778c&gt;] exit_to_kernel_mode+0xdc/0x10c arch/arm64/kernel/entry-common.c:95
hardirqs last disabled at (131135): [&lt;ffff80008ae85378&gt;] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]
hardirqs last disabled at (131135): [&lt;ffff80008ae85378&gt;] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551
softirqs last enabled at (125892): [&lt;ffff80008907e82c&gt;] neigh_hh_init net/core/neighbour.c:1538 [inline]
softirqs last enabled at (125892): [&lt;ffff80008907e82c&gt;] neigh_resolve_output+0x268/0x658 net/core/neighbour.c:1553
softirqs last disabled at (125896): [&lt;ffff80008904166c&gt;] local_bh_disable+0x10/0x34 include/linux/bottom_half.h:19
CPU: 1 PID: 24 Comm: kworker/1:0 Not tainted 6.9.0-rc7-syzkaller-gfda5695d692c #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
Workqueue: mld mld_ifc_work
pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : __list_del include/linux/list.h:195 [inline]
pc : __list_del_entry include/linux/list.h:218 [inline]
pc : list_move_tail include/linux/list.h:310 [inline]
pc : fq_tin_dequeue include/net/fq_impl.h:112 [inline]
pc : ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854
lr : __list_del_entry include/linux/list.h:218 [inline]
lr : list_move_tail include/linux/list.h:310 [inline]
lr : fq_tin_dequeue include/net/fq_impl.h:112 [inline]
lr : ieee80211_tx_dequeue+0x67c/0x3b4c net/mac80211/tx.c:3854
sp : ffff800093d36700
x29: ffff800093d36a60 x28: ffff800093d36960 x27: dfff800000000000
x26: ffff0000d800ad50 x25: ffff0000d800abe0 x24: ffff0000d800abf0
x23: ffff0000e0032468 x22: ffff0000e00324d4 x21: ffff0000d800abf0
x20: ffff0000d800abf8 x19: ffff0000d800abf0 x18: ffff800093d363c0
x17: 000000000000d476 x16: ffff8000805519dc x15: ffff7000127a6cc8
x14: 1ffff000127a6cc8 x13: 0000000000000004 x12: ffffffffffffffff
x11: ffff7000127a6cc8 x10: 0000000000ff0100 x9 : 0000000000000000
x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000
x5 : ffff80009287aa08 x4 : 0000000000000008 x3 : ffff80008034c7fc
x2 : ffff0000e0032468 x1 : 00000000da0e46b8 x0 : ffff0000e0032470
Call trace:
__list_del include/linux/list.h:195 [inline]
__list_del_entry include/linux/list.h:218 [inline]
list_move_tail include/linux/list.h:310 [inline]
fq_tin_dequeue include/net/fq_impl.h:112 [inline]
ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854
wake_tx_push_queue net/mac80211/util.c:294 [inline]
ieee80211_handle_wake_tx_queue+0x118/0x274 net/mac80211/util.c:315
drv_wake_tx_queue net/mac80211/driver-ops.h:1350 [inline]
schedule_and_wake_txq net/mac80211/driver-ops.h:1357 [inline]
ieee80211_queue_skb+0x18e8/0x2244 net/mac80211/tx.c:1664
ieee80211_tx+0x260/0x400 net/mac80211/tx.c:1966
ieee80211_xmit+0x278/0x354 net/mac80211/tx.c:2062
__ieee80211_subif_start_xmit+0xab8/0x122c net/mac80211/tx.c:4338
ieee80211_subif_start_xmit+0xe0/0x438 net/mac80211/tx.c:4532
__netdev_start_xmit include/linux/netdevice.h:4903 [inline]
netdev_start_xmit include/linux/netdevice.h:4917 [inline]
xmit_one net/core/dev.c:3531 [inline]
dev_hard_start_xmit+0x27c/0x938 net/core/dev.c:3547
__dev_queue_xmit+0x1678/0x33fc net/core/dev.c:4341
dev_queue_xmit include/linux/netdevice.h:3091 [inline]
neigh_resolve_output+0x558/0x658 net/core/neighbour.c:1563
neigh_output include/net/neighbour.h:542 [inline]
ip6_fini
---truncated---(CVE-2024-42114)
In the Linux kernel, the following vulnerability has been resolved:
s390/pkey: Use kfree_sensitive() to fix Coccinelle warnings
Replace memzero_explicit() and kfree() with kfree_sensitive() to fix
warnings 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 overflow
state-&gt;xtal_hz can be up to 16M, so it can overflow a 32 bit integer
when multiplied by pll_mfactor.
Create a new 64 bit variable to hold the calculations.(CVE-2024-42223)</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 high. 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">High</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-1993</URL>
</Reference>
<Reference Type="openEuler CVE">
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2023-52888</URL>
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39509</URL>
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-40956</URL>
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-40990</URL>
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-41035</URL>
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-41042</URL>
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-41046</URL>
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42105</URL>
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42114</URL>
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42158</URL>
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-42223</URL>
</Reference>
<Reference Type="Other">
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52888</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39509</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40956</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-40990</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41035</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41042</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-41046</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42105</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42114</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42158</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-42223</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-38.0.0.45" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">bpftool-6.6.0-38.0.0.45.oe2403.aarch64.rpm</FullProductName>
<FullProductName ProductID="bpftool-debuginfo-6.6.0-38.0.0.45" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">bpftool-debuginfo-6.6.0-38.0.0.45.oe2403.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-6.6.0-38.0.0.45" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-6.6.0-38.0.0.45.oe2403.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-debuginfo-6.6.0-38.0.0.45" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-debuginfo-6.6.0-38.0.0.45.oe2403.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-debugsource-6.6.0-38.0.0.45" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-debugsource-6.6.0-38.0.0.45.oe2403.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-devel-6.6.0-38.0.0.45" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-devel-6.6.0-38.0.0.45.oe2403.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-headers-6.6.0-38.0.0.45" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-headers-6.6.0-38.0.0.45.oe2403.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-source-6.6.0-38.0.0.45" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-source-6.6.0-38.0.0.45.oe2403.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-tools-6.6.0-38.0.0.45" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-tools-6.6.0-38.0.0.45.oe2403.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-tools-debuginfo-6.6.0-38.0.0.45" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-tools-debuginfo-6.6.0-38.0.0.45.oe2403.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-tools-devel-6.6.0-38.0.0.45" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-tools-devel-6.6.0-38.0.0.45.oe2403.aarch64.rpm</FullProductName>
<FullProductName ProductID="perf-6.6.0-38.0.0.45" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">perf-6.6.0-38.0.0.45.oe2403.aarch64.rpm</FullProductName>
<FullProductName ProductID="perf-debuginfo-6.6.0-38.0.0.45" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">perf-debuginfo-6.6.0-38.0.0.45.oe2403.aarch64.rpm</FullProductName>
<FullProductName ProductID="python3-perf-6.6.0-38.0.0.45" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">python3-perf-6.6.0-38.0.0.45.oe2403.aarch64.rpm</FullProductName>
<FullProductName ProductID="python3-perf-debuginfo-6.6.0-38.0.0.45" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">python3-perf-debuginfo-6.6.0-38.0.0.45.oe2403.aarch64.rpm</FullProductName>
</Branch>
<Branch Type="Package Arch" Name="x86_64">
<FullProductName ProductID="bpftool-6.6.0-38.0.0.45" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">bpftool-6.6.0-38.0.0.45.oe2403.x86_64.rpm</FullProductName>
<FullProductName ProductID="bpftool-debuginfo-6.6.0-38.0.0.45" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">bpftool-debuginfo-6.6.0-38.0.0.45.oe2403.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-6.6.0-38.0.0.45" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-6.6.0-38.0.0.45.oe2403.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-debuginfo-6.6.0-38.0.0.45" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-debuginfo-6.6.0-38.0.0.45.oe2403.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-debugsource-6.6.0-38.0.0.45" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-debugsource-6.6.0-38.0.0.45.oe2403.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-devel-6.6.0-38.0.0.45" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-devel-6.6.0-38.0.0.45.oe2403.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-headers-6.6.0-38.0.0.45" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-headers-6.6.0-38.0.0.45.oe2403.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-source-6.6.0-38.0.0.45" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-source-6.6.0-38.0.0.45.oe2403.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-tools-6.6.0-38.0.0.45" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-tools-6.6.0-38.0.0.45.oe2403.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-tools-debuginfo-6.6.0-38.0.0.45" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-tools-debuginfo-6.6.0-38.0.0.45.oe2403.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-tools-devel-6.6.0-38.0.0.45" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-tools-devel-6.6.0-38.0.0.45.oe2403.x86_64.rpm</FullProductName>
<FullProductName ProductID="perf-6.6.0-38.0.0.45" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">perf-6.6.0-38.0.0.45.oe2403.x86_64.rpm</FullProductName>
<FullProductName ProductID="perf-debuginfo-6.6.0-38.0.0.45" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">perf-debuginfo-6.6.0-38.0.0.45.oe2403.x86_64.rpm</FullProductName>
<FullProductName ProductID="python3-perf-6.6.0-38.0.0.45" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">python3-perf-6.6.0-38.0.0.45.oe2403.x86_64.rpm</FullProductName>
<FullProductName ProductID="python3-perf-debuginfo-6.6.0-38.0.0.45" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">python3-perf-debuginfo-6.6.0-38.0.0.45.oe2403.x86_64.rpm</FullProductName>
</Branch>
<Branch Type="Package Arch" Name="src">
<FullProductName ProductID="kernel-6.6.0-38.0.0.45" CPE="cpe:/a:openEuler:openEuler:24.03-LTS">kernel-6.6.0-38.0.0.45.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:
media: mediatek: vcodec: Only free buffer VA that is not NULL
In the MediaTek vcodec driver, while mtk_vcodec_mem_free() is mostly
called only when the buffer to free exists, there are some instances
that didn&apos;t do the check and triggered warnings in practice.
We believe those checks were forgotten unintentionally. Add the checks
back to fix the warnings.</Note>
</Notes>
<ReleaseDate>2024-08-16</ReleaseDate>
<CVE>CVE-2023-52888</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-08-16</DATE>
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1993</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:
HID: core: remove unnecessary WARN_ON() in implement()
Syzkaller hit a warning [1] in a call to implement() when trying
to write a value into a field of smaller size in an output report.
Since implement() already has a warn message printed out with the
help of hid_warn() and value in question gets trimmed with:
...
value &amp;= m;
...
WARN_ON may be considered superfluous. Remove it to suppress future
syzkaller triggers.
[1]
WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 implement drivers/hid/hid-core.c:1451 [inline]
WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863
Modules linked in:
CPU: 0 PID: 5084 Comm: syz-executor424 Not tainted 6.9.0-rc7-syzkaller-00183-gcf87f46fd34d #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
RIP: 0010:implement drivers/hid/hid-core.c:1451 [inline]
RIP: 0010:hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863
...
Call Trace:
&lt;TASK&gt;
__usbhid_submit_report drivers/hid/usbhid/hid-core.c:591 [inline]
usbhid_submit_report+0x43d/0x9e0 drivers/hid/usbhid/hid-core.c:636
hiddev_ioctl+0x138b/0x1f00 drivers/hid/usbhid/hiddev.c:726
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:904 [inline]
__se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
...</Note>
</Notes>
<ReleaseDate>2024-08-16</ReleaseDate>
<CVE>CVE-2024-39509</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-08-16</DATE>
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1993</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:
dmaengine: idxd: Fix possible Use-After-Free in irq_process_work_list
Use list_for_each_entry_safe() to allow iterating through the list and
deleting the entry in the iteration process. The descriptor is freed via
idxd_desc_complete() and there&apos;s a slight chance may cause issue for
the list iterator when the descriptor is reused by another thread
without it being deleted from the list.</Note>
</Notes>
<ReleaseDate>2024-08-16</ReleaseDate>
<CVE>CVE-2024-40956</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-24.03-LTS</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>High</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>7.0</BaseScore>
<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
</ScoreSet>
</CVSSScoreSets>
<Remediations>
<Remediation Type="Vendor Fix">
<Description>kernel security update</Description>
<DATE>2024-08-16</DATE>
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1993</URL>
</Remediation>
</Remediations>
</Vulnerability>
<Vulnerability Ordinal="4" 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:
RDMA/mlx5: Add check for srq max_sge attribute
max_sge attribute is passed by the user, and is inserted and used
unchecked, so verify that the value doesn&apos;t exceed maximum allowed value
before using it.</Note>
</Notes>
<ReleaseDate>2024-08-16</ReleaseDate>
<CVE>CVE-2024-40990</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-08-16</DATE>
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1993</URL>
</Remediation>
</Remediations>
</Vulnerability>
<Vulnerability Ordinal="5" 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: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor
Syzbot has identified a bug in usbcore (see the Closes: tag below)
caused by our assumption that the reserved bits in an endpoint
descriptor&apos;s bEndpointAddress field will always be 0. As a result of
the bug, the endpoint_is_duplicate() routine in config.c (and possibly
other routines as well) may believe that two descriptors are for
distinct endpoints, even though they have the same direction and
endpoint number. This can lead to confusion, including the bug
identified by syzbot (two descriptors with matching endpoint numbers
and directions, where one was interrupt and the other was bulk).
To fix the bug, we will clear the reserved bits in bEndpointAddress
when we parse the descriptor. (Note that both the USB-2.0 and USB-3.1
specs say these bits are &quot;Reserved, reset to zero&quot;.) This requires us
to make a copy of the descriptor earlier in usb_parse_endpoint() and
use the copy instead of the original when checking for duplicates.</Note>
</Notes>
<ReleaseDate>2024-08-16</ReleaseDate>
<CVE>CVE-2024-41035</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-08-16</DATE>
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1993</URL>
</Remediation>
</Remediations>
</Vulnerability>
<Vulnerability Ordinal="6" 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:
netfilter: nf_tables: prefer nft_chain_validate
nft_chain_validate already performs loop detection because a cycle will
result in a call stack overflow (ctx-&gt;level &gt;= NFT_JUMP_STACK_SIZE).
It also follows maps via -&gt;validate callback in nft_lookup, so there
appears no reason to iterate the maps again.
nf_tables_check_loops() and all its helper functions can be removed.
This improves ruleset load time significantly, from 23s down to 12s.
This also fixes a crash bug. Old loop detection code can result in
unbounded recursion:
BUG: TASK stack guard page was hit at ....
Oops: stack guard page: 0000 [#1] PREEMPT SMP KASAN
CPU: 4 PID: 1539 Comm: nft Not tainted 6.10.0-rc5+ #1
[..]
with a suitable ruleset during validation of register stores.
I can&apos;t see any actual reason to attempt to check for this from
nft_validate_register_store(), at this point the transaction is still in
progress, so we don&apos;t have a full picture of the rule graph.
For nf-next it might make sense to either remove it or make this depend
on table-&gt;validate_state in case we could catch an error earlier
(for improved error reporting to userspace).</Note>
</Notes>
<ReleaseDate>2024-08-16</ReleaseDate>
<CVE>CVE-2024-41042</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>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-08-16</DATE>
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1993</URL>
</Remediation>
</Remediations>
</Vulnerability>
<Vulnerability Ordinal="7" 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:
net: ethernet: lantiq_etop: fix double free in detach
The number of the currently released descriptor is never incremented
which results in the same skb being released multiple times.</Note>
</Notes>
<ReleaseDate>2024-08-16</ReleaseDate>
<CVE>CVE-2024-41046</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>6.7</BaseScore>
<Vector>AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H</Vector>
</ScoreSet>
</CVSSScoreSets>
<Remediations>
<Remediation Type="Vendor Fix">
<Description>kernel security update</Description>
<DATE>2024-08-16</DATE>
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1993</URL>
</Remediation>
</Remediations>
</Vulnerability>
<Vulnerability Ordinal="8" 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:
nilfs2: fix inode number range checks
Patch series &quot;nilfs2: fix potential issues related to reserved inodes&quot;.
This series fixes one use-after-free issue reported by syzbot, caused by
nilfs2&apos;s internal inode being exposed in the namespace on a corrupted
filesystem, and a couple of flaws that cause problems if the starting
number of non-reserved inodes written in the on-disk super block is
intentionally (or corruptly) changed from its default value.
This patch (of 3):
In the current implementation of nilfs2, &quot;nilfs-&gt;ns_first_ino&quot;, which
gives the first non-reserved inode number, is read from the superblock,
but its lower limit is not checked.
As a result, if a number that overlaps with the inode number range of
reserved inodes such as the root directory or metadata files is set in the
super block parameter, the inode number test macros (NILFS_MDT_INODE and
NILFS_VALID_INODE) will not function properly.
In addition, these test macros use left bit-shift calculations using with
the inode number as the shift count via the BIT macro, but the result of a
shift calculation that exceeds the bit width of an integer is undefined in
the C specification, so if &quot;ns_first_ino&quot; is set to a large value other
than the default value NILFS_USER_INO (=11), the macros may potentially
malfunction depending on the environment.
Fix these issues by checking the lower bound of &quot;nilfs-&gt;ns_first_ino&quot; and
by preventing bit shifts equal to or greater than the NILFS_USER_INO
constant in the inode number test macros.
Also, change the type of &quot;ns_first_ino&quot; from signed integer to unsigned
integer to avoid the need for type casting in comparisons such as the
lower bound check introduced this time.</Note>
</Notes>
<ReleaseDate>2024-08-16</ReleaseDate>
<CVE>CVE-2024-42105</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>6.1</BaseScore>
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H</Vector>
</ScoreSet>
</CVSSScoreSets>
<Remediations>
<Remediation Type="Vendor Fix">
<Description>kernel security update</Description>
<DATE>2024-08-16</DATE>
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1993</URL>
</Remediation>
</Remediations>
</Vulnerability>
<Vulnerability Ordinal="9" 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:
wifi: cfg80211: restrict NL80211_ATTR_TXQ_QUANTUM values
syzbot is able to trigger softlockups, setting NL80211_ATTR_TXQ_QUANTUM
to 2^31.
We had a similar issue in sch_fq, fixed with commit
d9e15a273306 (&quot;pkt_sched: fq: do not accept silly TCA_FQ_QUANTUM&quot;)
watchdog: BUG: soft lockup - CPU#1 stuck for 26s! [kworker/1:0:24]
Modules linked in:
irq event stamp: 131135
hardirqs last enabled at (131134): [&lt;ffff80008ae8778c&gt;] __exit_to_kernel_mode arch/arm64/kernel/entry-common.c:85 [inline]
hardirqs last enabled at (131134): [&lt;ffff80008ae8778c&gt;] exit_to_kernel_mode+0xdc/0x10c arch/arm64/kernel/entry-common.c:95
hardirqs last disabled at (131135): [&lt;ffff80008ae85378&gt;] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]
hardirqs last disabled at (131135): [&lt;ffff80008ae85378&gt;] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551
softirqs last enabled at (125892): [&lt;ffff80008907e82c&gt;] neigh_hh_init net/core/neighbour.c:1538 [inline]
softirqs last enabled at (125892): [&lt;ffff80008907e82c&gt;] neigh_resolve_output+0x268/0x658 net/core/neighbour.c:1553
softirqs last disabled at (125896): [&lt;ffff80008904166c&gt;] local_bh_disable+0x10/0x34 include/linux/bottom_half.h:19
CPU: 1 PID: 24 Comm: kworker/1:0 Not tainted 6.9.0-rc7-syzkaller-gfda5695d692c #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
Workqueue: mld mld_ifc_work
pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : __list_del include/linux/list.h:195 [inline]
pc : __list_del_entry include/linux/list.h:218 [inline]
pc : list_move_tail include/linux/list.h:310 [inline]
pc : fq_tin_dequeue include/net/fq_impl.h:112 [inline]
pc : ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854
lr : __list_del_entry include/linux/list.h:218 [inline]
lr : list_move_tail include/linux/list.h:310 [inline]
lr : fq_tin_dequeue include/net/fq_impl.h:112 [inline]
lr : ieee80211_tx_dequeue+0x67c/0x3b4c net/mac80211/tx.c:3854
sp : ffff800093d36700
x29: ffff800093d36a60 x28: ffff800093d36960 x27: dfff800000000000
x26: ffff0000d800ad50 x25: ffff0000d800abe0 x24: ffff0000d800abf0
x23: ffff0000e0032468 x22: ffff0000e00324d4 x21: ffff0000d800abf0
x20: ffff0000d800abf8 x19: ffff0000d800abf0 x18: ffff800093d363c0
x17: 000000000000d476 x16: ffff8000805519dc x15: ffff7000127a6cc8
x14: 1ffff000127a6cc8 x13: 0000000000000004 x12: ffffffffffffffff
x11: ffff7000127a6cc8 x10: 0000000000ff0100 x9 : 0000000000000000
x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000
x5 : ffff80009287aa08 x4 : 0000000000000008 x3 : ffff80008034c7fc
x2 : ffff0000e0032468 x1 : 00000000da0e46b8 x0 : ffff0000e0032470
Call trace:
__list_del include/linux/list.h:195 [inline]
__list_del_entry include/linux/list.h:218 [inline]
list_move_tail include/linux/list.h:310 [inline]
fq_tin_dequeue include/net/fq_impl.h:112 [inline]
ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854
wake_tx_push_queue net/mac80211/util.c:294 [inline]
ieee80211_handle_wake_tx_queue+0x118/0x274 net/mac80211/util.c:315
drv_wake_tx_queue net/mac80211/driver-ops.h:1350 [inline]
schedule_and_wake_txq net/mac80211/driver-ops.h:1357 [inline]
ieee80211_queue_skb+0x18e8/0x2244 net/mac80211/tx.c:1664
ieee80211_tx+0x260/0x400 net/mac80211/tx.c:1966
ieee80211_xmit+0x278/0x354 net/mac80211/tx.c:2062
__ieee80211_subif_start_xmit+0xab8/0x122c net/mac80211/tx.c:4338
ieee80211_subif_start_xmit+0xe0/0x438 net/mac80211/tx.c:4532
__netdev_start_xmit include/linux/netdevice.h:4903 [inline]
netdev_start_xmit include/linux/netdevice.h:4917 [inline]
xmit_one net/core/dev.c:3531 [inline]
dev_hard_start_xmit+0x27c/0x938 net/core/dev.c:3547
__dev_queue_xmit+0x1678/0x33fc net/core/dev.c:4341
dev_queue_xmit include/linux/netdevice.h:3091 [inline]
neigh_resolve_output+0x558/0x658 net/core/neighbour.c:1563
neigh_output include/net/neighbour.h:542 [inline]
ip6_fini
---truncated---</Note>
</Notes>
<ReleaseDate>2024-08-16</ReleaseDate>
<CVE>CVE-2024-42114</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-08-16</DATE>
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1993</URL>
</Remediation>
</Remediations>
</Vulnerability>
<Vulnerability Ordinal="10" 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: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)</Note>
</Notes>
<ReleaseDate>2024-08-16</ReleaseDate>
<CVE>CVE-2024-42158</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>4.1</BaseScore>
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N</Vector>
</ScoreSet>
</CVSSScoreSets>
<Remediations>
<Remediation Type="Vendor Fix">
<Description>kernel security update</Description>
<DATE>2024-08-16</DATE>
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1993</URL>
</Remediation>
</Remediations>
</Vulnerability>
<Vulnerability Ordinal="11" 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: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.</Note>
</Notes>
<ReleaseDate>2024-08-16</ReleaseDate>
<CVE>CVE-2024-42223</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-08-16</DATE>
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1993</URL>
</Remediation>
</Remediations>
</Vulnerability>
</cvrfdoc>
Reference in New Issue View Git Blame Copy Permalink