jiachao2130/cvrf2cusa
1
0
Fork 1
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
7d8412e76d
cvrf2cusa/cvrf/2024/cvrf-openEuler-SA-2024-1862.xml
Jia Chao 0b34274085 git mv 
Signed-off-by: Jia Chao <jiac13@chinaunicom.cn>
2024-07-25 09:57:37 +08:00

1380 lines
60 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-20.03-LTS-SP4</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-1862</ID>
</Identification>
<Status>Final</Status>
<Version>1.0</Version>
<RevisionHistory>
<Revision>
<Number>1.0</Number>
<Date>2024-07-19</Date>
<Description>Initial</Description>
</Revision>
</RevisionHistory>
<InitialReleaseDate>2024-07-19</InitialReleaseDate>
<CurrentReleaseDate>2024-07-19</CurrentReleaseDate>
<Generator>
<Engine>openEuler SA Tool V1.0</Engine>
<Date>2024-07-19</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-20.03-LTS-SP4</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:
KVM: PPC: Fix kvm_arch_vcpu_ioctl vcpu_load leak
vcpu_put is not called if the user copy fails. This can result in preempt
notifier corruption and crashes, among other issues.(CVE-2021-47296)
In the Linux kernel, the following vulnerability has been resolved:
net: qcom/emac: fix UAF in emac_remove
adpt is netdev private data and it cannot be
used after free_netdev() call. Using adpt after free_netdev()
can cause UAF bug. Fix it by moving free_netdev() at the end of the
function.(CVE-2021-47311)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/cma: Ensure rdma_addr_cancel() happens before issuing more requests
The FSM can run in a circle allowing rdma_resolve_ip() to be called twice
on the same id_priv. While this cannot happen without going through the
work, it violates the invariant that the same address resolution
background request cannot be active twice.
CPU 1 CPU 2
rdma_resolve_addr():
RDMA_CM_IDLE -&gt; RDMA_CM_ADDR_QUERY
rdma_resolve_ip(addr_handler) #1
process_one_req(): for #1
addr_handler():
RDMA_CM_ADDR_QUERY -&gt; RDMA_CM_ADDR_BOUND
mutex_unlock(&amp;id_priv-&gt;handler_mutex);
[.. handler still running ..]
rdma_resolve_addr():
RDMA_CM_ADDR_BOUND -&gt; RDMA_CM_ADDR_QUERY
rdma_resolve_ip(addr_handler)
!! two requests are now on the req_list
rdma_destroy_id():
destroy_id_handler_unlock():
_destroy_id():
cma_cancel_operation():
rdma_addr_cancel()
// process_one_req() self removes it
spin_lock_bh(&amp;lock);
cancel_delayed_work(&amp;req-&gt;work);
if (!list_empty(&amp;req-&gt;list)) == true
! rdma_addr_cancel() returns after process_on_req #1 is done
kfree(id_priv)
process_one_req(): for #2
addr_handler():
mutex_lock(&amp;id_priv-&gt;handler_mutex);
!! Use after free on id_priv
rdma_addr_cancel() expects there to be one req on the list and only
cancels the first one. The self-removal behavior of the work only happens
after the handler has returned. This yields a situations where the
req_list can have two reqs for the same &quot;handle&quot; but rdma_addr_cancel()
only cancels the first one.
The second req remains active beyond rdma_destroy_id() and will
use-after-free id_priv once it inevitably triggers.
Fix this by remembering if the id_priv has called rdma_resolve_ip() and
always cancel before calling it again. This ensures the req_list never
gets more than one item in it and doesn&apos;t cost anything in the normal flow
that never uses this strange error path.(CVE-2021-47391)
In the Linux kernel, the following vulnerability has been resolved:
sch_cake: do not call cake_destroy() from cake_init()
qdiscs are not supposed to call their own destroy() method
from init(), because core stack already does that.
syzbot was able to trigger use after free:
DEBUG_LOCKS_WARN_ON(lock-&gt;magic != lock)
WARNING: CPU: 0 PID: 21902 at kernel/locking/mutex.c:586 __mutex_lock_common kernel/locking/mutex.c:586 [inline]
WARNING: CPU: 0 PID: 21902 at kernel/locking/mutex.c:586 __mutex_lock+0x9ec/0x12f0 kernel/locking/mutex.c:740
Modules linked in:
CPU: 0 PID: 21902 Comm: syz-executor189 Not tainted 5.16.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:__mutex_lock_common kernel/locking/mutex.c:586 [inline]
RIP: 0010:__mutex_lock+0x9ec/0x12f0 kernel/locking/mutex.c:740
Code: 08 84 d2 0f 85 19 08 00 00 8b 05 97 38 4b 04 85 c0 0f 85 27 f7 ff ff 48 c7 c6 20 00 ac 89 48 c7 c7 a0 fe ab 89 e8 bf 76 ba ff &lt;0f&gt; 0b e9 0d f7 ff ff 48 8b 44 24 40 48 8d b8 c8 08 00 00 48 89 f8
RSP: 0018:ffffc9000627f290 EFLAGS: 00010282
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: ffff88802315d700 RSI: ffffffff815f1db8 RDI: fffff52000c4fe44
RBP: ffff88818f28e000 R08: 0000000000000000 R09: 0000000000000000
R10: ffffffff815ebb5e R11: 0000000000000000 R12: 0000000000000000
R13: dffffc0000000000 R14: ffffc9000627f458 R15: 0000000093c30000
FS: 0000555556abc400(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fda689c3303 CR3: 000000001cfbb000 CR4: 0000000000350ef0
Call Trace:
&lt;TASK&gt;
tcf_chain0_head_change_cb_del+0x2e/0x3d0 net/sched/cls_api.c:810
tcf_block_put_ext net/sched/cls_api.c:1381 [inline]
tcf_block_put_ext net/sched/cls_api.c:1376 [inline]
tcf_block_put+0xbc/0x130 net/sched/cls_api.c:1394
cake_destroy+0x3f/0x80 net/sched/sch_cake.c:2695
qdisc_create.constprop.0+0x9da/0x10f0 net/sched/sch_api.c:1293
tc_modify_qdisc+0x4c5/0x1980 net/sched/sch_api.c:1660
rtnetlink_rcv_msg+0x413/0xb80 net/core/rtnetlink.c:5571
netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2496
netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1345
netlink_sendmsg+0x904/0xdf0 net/netlink/af_netlink.c:1921
sock_sendmsg_nosec net/socket.c:704 [inline]
sock_sendmsg+0xcf/0x120 net/socket.c:724
____sys_sendmsg+0x6e8/0x810 net/socket.c:2409
___sys_sendmsg+0xf3/0x170 net/socket.c:2463
__sys_sendmsg+0xe5/0x1b0 net/socket.c:2492
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f1bb06badb9
Code: Unable to access opcode bytes at RIP 0x7f1bb06bad8f.
RSP: 002b:00007fff3012a658 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f1bb06badb9
RDX: 0000000000000000 RSI: 00000000200007c0 RDI: 0000000000000003
RBP: 0000000000000000 R08: 0000000000000003 R09: 0000000000000003
R10: 0000000000000003 R11: 0000000000000246 R12: 00007fff3012a688
R13: 00007fff3012a6a0 R14: 00007fff3012a6e0 R15: 00000000000013c2
&lt;/TASK&gt;(CVE-2021-47598)
In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau: fix off by one in BIOS boundary checking
Bounds checking when parsing init scripts embedded in the BIOS reject
access to the last byte. This causes driver initialization to fail on
Apple eMac&apos;s with GeForce 2 MX GPUs, leaving the system with no working
console.
This is probably only seen on OpenFirmware machines like PowerPC Macs
because the BIOS image provided by OF is only the used parts of the ROM,
not a power-of-two blocks read from PCI directly so PCs always have
empty bytes at the end that are never accessed.(CVE-2022-48732)
In the Linux kernel, the following vulnerability has been resolved:
net: fix information leakage in /proc/net/ptype
In one net namespace, after creating a packet socket without binding
it to a device, users in other net namespaces can observe the new
`packet_type` added by this packet socket by reading `/proc/net/ptype`
file. This is minor information leakage as packet socket is
namespace aware.
Add a net pointer in `packet_type` to keep the net namespace of
of corresponding packet socket. In `ptype_seq_show`, this net pointer
must be checked when it is not NULL.(CVE-2022-48757)
In the Linux kernel, the following vulnerability has been resolved:
USB: core: Fix hang in usb_kill_urb by adding memory barriers
The syzbot fuzzer has identified a bug in which processes hang waiting
for usb_kill_urb() to return. It turns out the issue is not unlinking
the URB; that works just fine. Rather, the problem arises when the
wakeup notification that the URB has completed is not received.
The reason is memory-access ordering on SMP systems. In outline form,
usb_kill_urb() and __usb_hcd_giveback_urb() operating concurrently on
different CPUs perform the following actions:
CPU 0 CPU 1
---------------------------- ---------------------------------
usb_kill_urb(): __usb_hcd_giveback_urb():
... ...
atomic_inc(&amp;urb-&gt;reject); atomic_dec(&amp;urb-&gt;use_count);
... ...
wait_event(usb_kill_urb_queue,
atomic_read(&amp;urb-&gt;use_count) == 0);
if (atomic_read(&amp;urb-&gt;reject))
wake_up(&amp;usb_kill_urb_queue);
Confining your attention to urb-&gt;reject and urb-&gt;use_count, you can
see that the overall pattern of accesses on CPU 0 is:
write urb-&gt;reject, then read urb-&gt;use_count;
whereas the overall pattern of accesses on CPU 1 is:
write urb-&gt;use_count, then read urb-&gt;reject.
This pattern is referred to in memory-model circles as SB (for &quot;Store
Buffering&quot;), and it is well known that without suitable enforcement of
the desired order of accesses -- in the form of memory barriers -- it
is entirely possible for one or both CPUs to execute their reads ahead
of their writes. The end result will be that sometimes CPU 0 sees the
old un-decremented value of urb-&gt;use_count while CPU 1 sees the old
un-incremented value of urb-&gt;reject. Consequently CPU 0 ends up on
the wait queue and never gets woken up, leading to the observed hang
in usb_kill_urb().
The same pattern of accesses occurs in usb_poison_urb() and the
failure pathway of usb_hcd_submit_urb().
The problem is fixed by adding suitable memory barriers. To provide
proper memory-access ordering in the SB pattern, a full barrier is
required on both CPUs. The atomic_inc() and atomic_dec() accesses
themselves don&apos;t provide any memory ordering, but since they are
present, we can use the optimized smp_mb__after_atomic() memory
barrier in the various routines to obtain the desired effect.
This patch adds the necessary memory barriers.(CVE-2022-48760)
In the Linux kernel, the following vulnerability has been resolved:
net: openvswitch: fix overwriting ct original tuple for ICMPv6
OVS_PACKET_CMD_EXECUTE has 3 main attributes:
- OVS_PACKET_ATTR_KEY - Packet metadata in a netlink format.
- OVS_PACKET_ATTR_PACKET - Binary packet content.
- OVS_PACKET_ATTR_ACTIONS - Actions to execute on the packet.
OVS_PACKET_ATTR_KEY is parsed first to populate sw_flow_key structure
with the metadata like conntrack state, input port, recirculation id,
etc. Then the packet itself gets parsed to populate the rest of the
keys from the packet headers.
Whenever the packet parsing code starts parsing the ICMPv6 header, it
first zeroes out fields in the key corresponding to Neighbor Discovery
information even if it is not an ND packet.
It is an &apos;ipv6.nd&apos; field. However, the &apos;ipv6&apos; is a union that shares
the space between &apos;nd&apos; and &apos;ct_orig&apos; that holds the original tuple
conntrack metadata parsed from the OVS_PACKET_ATTR_KEY.
ND packets should not normally have conntrack state, so it&apos;s fine to
share the space, but normal ICMPv6 Echo packets or maybe other types of
ICMPv6 can have the state attached and it should not be overwritten.
The issue results in all but the last 4 bytes of the destination
address being wiped from the original conntrack tuple leading to
incorrect packet matching and potentially executing wrong actions
in case this packet recirculates within the datapath or goes back
to userspace.
ND fields should not be accessed in non-ND packets, so not clearing
them should be fine. Executing memset() only for actual ND packets to
avoid the issue.
Initializing the whole thing before parsing is needed because ND packet
may not contain all the options.
The issue only affects the OVS_PACKET_CMD_EXECUTE path and doesn&apos;t
affect packets entering OVS datapath from network interfaces, because
in this case CT metadata is populated from skb after the packet is
already parsed.(CVE-2024-38558)
In the Linux kernel, the following vulnerability has been resolved:
vfio/pci: fix potential memory leak in vfio_intx_enable()
If vfio_irq_ctx_alloc() failed will lead to &apos;name&apos; memory leak.(CVE-2024-38632)
In the Linux kernel, the following vulnerability has been resolved:
kdb: Fix buffer overflow during tab-complete
Currently, when the user attempts symbol completion with the Tab key, kdb
will use strncpy() to insert the completed symbol into the command buffer.
Unfortunately it passes the size of the source buffer rather than the
destination to strncpy() with predictably horrible results. Most obviously
if the command buffer is already full but cp, the cursor position, is in
the middle of the buffer, then we will write past the end of the supplied
buffer.
Fix this by replacing the dubious strncpy() calls with memmove()/memcpy()
calls plus explicit boundary checks to make sure we have enough space
before we start moving characters around.(CVE-2024-39480)
In the Linux kernel, the following vulnerability has been resolved:
bonding: Fix out-of-bounds read in bond_option_arp_ip_targets_set()
In function bond_option_arp_ip_targets_set(), if newval-&gt;string is an
empty string, newval-&gt;string+1 will point to the byte after the
string, causing an out-of-bound read.
BUG: KASAN: slab-out-of-bounds in strlen+0x7d/0xa0 lib/string.c:418
Read of size 1 at addr ffff8881119c4781 by task syz-executor665/8107
CPU: 1 PID: 8107 Comm: syz-executor665 Not tainted 6.7.0-rc7 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Call Trace:
&lt;TASK&gt;
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106
print_address_description mm/kasan/report.c:364 [inline]
print_report+0xc1/0x5e0 mm/kasan/report.c:475
kasan_report+0xbe/0xf0 mm/kasan/report.c:588
strlen+0x7d/0xa0 lib/string.c:418
__fortify_strlen include/linux/fortify-string.h:210 [inline]
in4_pton+0xa3/0x3f0 net/core/utils.c:130
bond_option_arp_ip_targets_set+0xc2/0x910
drivers/net/bonding/bond_options.c:1201
__bond_opt_set+0x2a4/0x1030 drivers/net/bonding/bond_options.c:767
__bond_opt_set_notify+0x48/0x150 drivers/net/bonding/bond_options.c:792
bond_opt_tryset_rtnl+0xda/0x160 drivers/net/bonding/bond_options.c:817
bonding_sysfs_store_option+0xa1/0x120 drivers/net/bonding/bond_sysfs.c:156
dev_attr_store+0x54/0x80 drivers/base/core.c:2366
sysfs_kf_write+0x114/0x170 fs/sysfs/file.c:136
kernfs_fop_write_iter+0x337/0x500 fs/kernfs/file.c:334
call_write_iter include/linux/fs.h:2020 [inline]
new_sync_write fs/read_write.c:491 [inline]
vfs_write+0x96a/0xd80 fs/read_write.c:584
ksys_write+0x122/0x250 fs/read_write.c:637
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
---[ end trace ]---
Fix it by adding a check of string length before using it.(CVE-2024-39487)
In the Linux kernel, the following vulnerability has been resolved:
arm64: asm-bug: Add .align 2 to the end of __BUG_ENTRY
When CONFIG_DEBUG_BUGVERBOSE=n, we fail to add necessary padding bytes
to bug_table entries, and as a result the last entry in a bug table will
be ignored, potentially leading to an unexpected panic(). All prior
entries in the table will be handled correctly.
The arm64 ABI requires that struct fields of up to 8 bytes are
naturally-aligned, with padding added within a struct such that struct
are suitably aligned within arrays.
When CONFIG_DEBUG_BUGVERPOSE=y, the layout of a bug_entry is:
struct bug_entry {
signed int bug_addr_disp; // 4 bytes
signed int file_disp; // 4 bytes
unsigned short line; // 2 bytes
unsigned short flags; // 2 bytes
}
... with 12 bytes total, requiring 4-byte alignment.
When CONFIG_DEBUG_BUGVERBOSE=n, the layout of a bug_entry is:
struct bug_entry {
signed int bug_addr_disp; // 4 bytes
unsigned short flags; // 2 bytes
&lt; implicit padding &gt; // 2 bytes
}
... with 8 bytes total, with 6 bytes of data and 2 bytes of trailing
padding, requiring 4-byte alginment.
When we create a bug_entry in assembly, we align the start of the entry
to 4 bytes, which implicitly handles padding for any prior entries.
However, we do not align the end of the entry, and so when
CONFIG_DEBUG_BUGVERBOSE=n, the final entry lacks the trailing padding
bytes.
For the main kernel image this is not a problem as find_bug() doesn&apos;t
depend on the trailing padding bytes when searching for entries:
for (bug = __start___bug_table; bug &lt; __stop___bug_table; ++bug)
if (bugaddr == bug_addr(bug))
return bug;
However for modules, module_bug_finalize() depends on the trailing
bytes when calculating the number of entries:
mod-&gt;num_bugs = sechdrs[i].sh_size / sizeof(struct bug_entry);
... and as the last bug_entry lacks the necessary padding bytes, this entry
will not be counted, e.g. in the case of a single entry:
sechdrs[i].sh_size == 6
sizeof(struct bug_entry) == 8;
sechdrs[i].sh_size / sizeof(struct bug_entry) == 0;
Consequently module_find_bug() will miss the last bug_entry when it does:
for (i = 0; i &lt; mod-&gt;num_bugs; ++i, ++bug)
if (bugaddr == bug_addr(bug))
goto out;
... which can lead to a kenrel panic due to an unhandled bug.
This can be demonstrated with the following module:
static int __init buginit(void)
{
WARN(1, &quot;hello\n&quot;);
return 0;
}
static void __exit bugexit(void)
{
}
module_init(buginit);
module_exit(bugexit);
MODULE_LICENSE(&quot;GPL&quot;);
... which will trigger a kernel panic when loaded:
------------[ cut here ]------------
hello
Unexpected kernel BRK exception at EL1
Internal error: BRK handler: 00000000f2000800 [#1] PREEMPT SMP
Modules linked in: hello(O+)
CPU: 0 PID: 50 Comm: insmod Tainted: G O 6.9.1 #8
Hardware name: linux,dummy-virt (DT)
pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : buginit+0x18/0x1000 [hello]
lr : buginit+0x18/0x1000 [hello]
sp : ffff800080533ae0
x29: ffff800080533ae0 x28: 0000000000000000 x27: 0000000000000000
x26: ffffaba8c4e70510 x25: ffff800080533c30 x24: ffffaba8c4a28a58
x23: 0000000000000000 x22: 0000000000000000 x21: ffff3947c0eab3c0
x20: ffffaba8c4e3f000 x19: ffffaba846464000 x18: 0000000000000006
x17: 0000000000000000 x16: ffffaba8c2492834 x15: 0720072007200720
x14: 0720072007200720 x13: ffffaba8c49b27c8 x12: 0000000000000312
x11: 0000000000000106 x10: ffffaba8c4a0a7c8 x9 : ffffaba8c49b27c8
x8 : 00000000ffffefff x7 : ffffaba8c4a0a7c8 x6 : 80000000fffff000
x5 : 0000000000000107 x4 : 0000000000000000 x3 : 0000000000000000
x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff3947c0eab3c0
Call trace:
buginit+0x18/0x1000 [hello]
do_one_initcall+0x80/0x1c8
do_init_module+0x60/0x218
load_module+0x1ba4/0x1d70
__do_sys_init_module+0x198/0x1d0
__arm64_sys_init_module+0x1c/0x28
invoke_syscall+0x48/0x114
el0_svc
---truncated---(CVE-2024-39488)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: sr: fix memleak in seg6_hmac_init_algo
seg6_hmac_init_algo returns without cleaning up the previous allocations
if one fails, so it&apos;s going to leak all that memory and the crypto tfms.
Update seg6_hmac_exit to only free the memory when allocated, so we can
reuse the code directly.(CVE-2024-39489)</Note>
<Note Title="Topic" Type="General" Ordinal="4" xml:lang="en">An update for kernel is now available for openEuler-20.03-LTS-SP4.
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-1862</URL>
</Reference>
<Reference Type="openEuler CVE">
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2021-47296</URL>
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2021-47311</URL>
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2021-47391</URL>
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2021-47598</URL>
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-48732</URL>
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-48757</URL>
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2022-48760</URL>
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38558</URL>
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-38632</URL>
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39480</URL>
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39487</URL>
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39488</URL>
<URL>https://www.openeuler.org/en/security/cve/detail/?cveId=CVE-2024-39489</URL>
</Reference>
<Reference Type="Other">
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47296</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47311</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47391</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47598</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48732</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48757</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48760</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38558</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38632</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39480</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39487</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39488</URL>
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-39489</URL>
</Reference>
</DocumentReferences>
<ProductTree xmlns="http://www.icasi.org/CVRF/schema/prod/1.1">
<Branch Type="Product Name" Name="openEuler">
<FullProductName ProductID="openEuler-20.03-LTS-SP4" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">openEuler-20.03-LTS-SP4</FullProductName>
</Branch>
<Branch Type="Package Arch" Name="aarch64">
<FullProductName ProductID="bpftool-4.19.90-2407.4.0.0286" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-4.19.90-2407.4.0.0286.oe2003sp4.aarch64.rpm</FullProductName>
<FullProductName ProductID="bpftool-debuginfo-4.19.90-2407.4.0.0286" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-debuginfo-4.19.90-2407.4.0.0286.oe2003sp4.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-4.19.90-2407.4.0.0286" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-4.19.90-2407.4.0.0286.oe2003sp4.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-debuginfo-4.19.90-2407.4.0.0286" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debuginfo-4.19.90-2407.4.0.0286.oe2003sp4.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-debugsource-4.19.90-2407.4.0.0286" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debugsource-4.19.90-2407.4.0.0286.oe2003sp4.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-devel-4.19.90-2407.4.0.0286" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-devel-4.19.90-2407.4.0.0286.oe2003sp4.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-source-4.19.90-2407.4.0.0286" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-source-4.19.90-2407.4.0.0286.oe2003sp4.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-tools-4.19.90-2407.4.0.0286" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-4.19.90-2407.4.0.0286.oe2003sp4.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-tools-debuginfo-4.19.90-2407.4.0.0286" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-debuginfo-4.19.90-2407.4.0.0286.oe2003sp4.aarch64.rpm</FullProductName>
<FullProductName ProductID="kernel-tools-devel-4.19.90-2407.4.0.0286" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-devel-4.19.90-2407.4.0.0286.oe2003sp4.aarch64.rpm</FullProductName>
<FullProductName ProductID="perf-4.19.90-2407.4.0.0286" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-4.19.90-2407.4.0.0286.oe2003sp4.aarch64.rpm</FullProductName>
<FullProductName ProductID="perf-debuginfo-4.19.90-2407.4.0.0286" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-debuginfo-4.19.90-2407.4.0.0286.oe2003sp4.aarch64.rpm</FullProductName>
<FullProductName ProductID="python2-perf-4.19.90-2407.4.0.0286" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-4.19.90-2407.4.0.0286.oe2003sp4.aarch64.rpm</FullProductName>
<FullProductName ProductID="python2-perf-debuginfo-4.19.90-2407.4.0.0286" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-debuginfo-4.19.90-2407.4.0.0286.oe2003sp4.aarch64.rpm</FullProductName>
<FullProductName ProductID="python3-perf-4.19.90-2407.4.0.0286" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-4.19.90-2407.4.0.0286.oe2003sp4.aarch64.rpm</FullProductName>
<FullProductName ProductID="python3-perf-debuginfo-4.19.90-2407.4.0.0286" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-debuginfo-4.19.90-2407.4.0.0286.oe2003sp4.aarch64.rpm</FullProductName>
</Branch>
<Branch Type="Package Arch" Name="x86_64">
<FullProductName ProductID="bpftool-4.19.90-2407.4.0.0286" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-4.19.90-2407.4.0.0286.oe2003sp4.x86_64.rpm</FullProductName>
<FullProductName ProductID="bpftool-debuginfo-4.19.90-2407.4.0.0286" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-debuginfo-4.19.90-2407.4.0.0286.oe2003sp4.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-4.19.90-2407.4.0.0286" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-4.19.90-2407.4.0.0286.oe2003sp4.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-debuginfo-4.19.90-2407.4.0.0286" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debuginfo-4.19.90-2407.4.0.0286.oe2003sp4.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-debugsource-4.19.90-2407.4.0.0286" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debugsource-4.19.90-2407.4.0.0286.oe2003sp4.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-devel-4.19.90-2407.4.0.0286" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-devel-4.19.90-2407.4.0.0286.oe2003sp4.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-source-4.19.90-2407.4.0.0286" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-source-4.19.90-2407.4.0.0286.oe2003sp4.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-tools-4.19.90-2407.4.0.0286" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-4.19.90-2407.4.0.0286.oe2003sp4.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-tools-debuginfo-4.19.90-2407.4.0.0286" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-debuginfo-4.19.90-2407.4.0.0286.oe2003sp4.x86_64.rpm</FullProductName>
<FullProductName ProductID="kernel-tools-devel-4.19.90-2407.4.0.0286" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-devel-4.19.90-2407.4.0.0286.oe2003sp4.x86_64.rpm</FullProductName>
<FullProductName ProductID="perf-4.19.90-2407.4.0.0286" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-4.19.90-2407.4.0.0286.oe2003sp4.x86_64.rpm</FullProductName>
<FullProductName ProductID="perf-debuginfo-4.19.90-2407.4.0.0286" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-debuginfo-4.19.90-2407.4.0.0286.oe2003sp4.x86_64.rpm</FullProductName>
<FullProductName ProductID="python2-perf-4.19.90-2407.4.0.0286" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-4.19.90-2407.4.0.0286.oe2003sp4.x86_64.rpm</FullProductName>
<FullProductName ProductID="python2-perf-debuginfo-4.19.90-2407.4.0.0286" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-debuginfo-4.19.90-2407.4.0.0286.oe2003sp4.x86_64.rpm</FullProductName>
<FullProductName ProductID="python3-perf-4.19.90-2407.4.0.0286" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-4.19.90-2407.4.0.0286.oe2003sp4.x86_64.rpm</FullProductName>
<FullProductName ProductID="python3-perf-debuginfo-4.19.90-2407.4.0.0286" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-debuginfo-4.19.90-2407.4.0.0286.oe2003sp4.x86_64.rpm</FullProductName>
</Branch>
<Branch Type="Package Arch" Name="src">
<FullProductName ProductID="kernel-4.19.90-2407.4.0.0286" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-4.19.90-2407.4.0.0286.oe2003sp4.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:
KVM: PPC: Fix kvm_arch_vcpu_ioctl vcpu_load leak
vcpu_put is not called if the user copy fails. This can result in preempt
notifier corruption and crashes, among other issues.</Note>
</Notes>
<ReleaseDate>2024-07-19</ReleaseDate>
<CVE>CVE-2021-47296</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>Low</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-19</DATE>
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1862</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:
net: qcom/emac: fix UAF in emac_remove
adpt is netdev private data and it cannot be
used after free_netdev() call. Using adpt after free_netdev()
can cause UAF bug. Fix it by moving free_netdev() at the end of the
function.</Note>
</Notes>
<ReleaseDate>2024-07-19</ReleaseDate>
<CVE>CVE-2021-47311</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-20.03-LTS-SP4</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-07-19</DATE>
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1862</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:
RDMA/cma: Ensure rdma_addr_cancel() happens before issuing more requests
The FSM can run in a circle allowing rdma_resolve_ip() to be called twice
on the same id_priv. While this cannot happen without going through the
work, it violates the invariant that the same address resolution
background request cannot be active twice.
CPU 1 CPU 2
rdma_resolve_addr():
RDMA_CM_IDLE -&gt; RDMA_CM_ADDR_QUERY
rdma_resolve_ip(addr_handler) #1
process_one_req(): for #1
addr_handler():
RDMA_CM_ADDR_QUERY -&gt; RDMA_CM_ADDR_BOUND
mutex_unlock(&amp;id_priv-&gt;handler_mutex);
[.. handler still running ..]
rdma_resolve_addr():
RDMA_CM_ADDR_BOUND -&gt; RDMA_CM_ADDR_QUERY
rdma_resolve_ip(addr_handler)
!! two requests are now on the req_list
rdma_destroy_id():
destroy_id_handler_unlock():
_destroy_id():
cma_cancel_operation():
rdma_addr_cancel()
// process_one_req() self removes it
spin_lock_bh(&amp;lock);
cancel_delayed_work(&amp;req-&gt;work);
if (!list_empty(&amp;req-&gt;list)) == true
! rdma_addr_cancel() returns after process_on_req #1 is done
kfree(id_priv)
process_one_req(): for #2
addr_handler():
mutex_lock(&amp;id_priv-&gt;handler_mutex);
!! Use after free on id_priv
rdma_addr_cancel() expects there to be one req on the list and only
cancels the first one. The self-removal behavior of the work only happens
after the handler has returned. This yields a situations where the
req_list can have two reqs for the same &quot;handle&quot; but rdma_addr_cancel()
only cancels the first one.
The second req remains active beyond rdma_destroy_id() and will
use-after-free id_priv once it inevitably triggers.
Fix this by remembering if the id_priv has called rdma_resolve_ip() and
always cancel before calling it again. This ensures the req_list never
gets more than one item in it and doesn&apos;t cost anything in the normal flow
that never uses this strange error path.</Note>
</Notes>
<ReleaseDate>2024-07-19</ReleaseDate>
<CVE>CVE-2021-47391</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>Low</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-19</DATE>
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1862</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:
sch_cake: do not call cake_destroy() from cake_init()
qdiscs are not supposed to call their own destroy() method
from init(), because core stack already does that.
syzbot was able to trigger use after free:
DEBUG_LOCKS_WARN_ON(lock-&gt;magic != lock)
WARNING: CPU: 0 PID: 21902 at kernel/locking/mutex.c:586 __mutex_lock_common kernel/locking/mutex.c:586 [inline]
WARNING: CPU: 0 PID: 21902 at kernel/locking/mutex.c:586 __mutex_lock+0x9ec/0x12f0 kernel/locking/mutex.c:740
Modules linked in:
CPU: 0 PID: 21902 Comm: syz-executor189 Not tainted 5.16.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:__mutex_lock_common kernel/locking/mutex.c:586 [inline]
RIP: 0010:__mutex_lock+0x9ec/0x12f0 kernel/locking/mutex.c:740
Code: 08 84 d2 0f 85 19 08 00 00 8b 05 97 38 4b 04 85 c0 0f 85 27 f7 ff ff 48 c7 c6 20 00 ac 89 48 c7 c7 a0 fe ab 89 e8 bf 76 ba ff &lt;0f&gt; 0b e9 0d f7 ff ff 48 8b 44 24 40 48 8d b8 c8 08 00 00 48 89 f8
RSP: 0018:ffffc9000627f290 EFLAGS: 00010282
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: ffff88802315d700 RSI: ffffffff815f1db8 RDI: fffff52000c4fe44
RBP: ffff88818f28e000 R08: 0000000000000000 R09: 0000000000000000
R10: ffffffff815ebb5e R11: 0000000000000000 R12: 0000000000000000
R13: dffffc0000000000 R14: ffffc9000627f458 R15: 0000000093c30000
FS: 0000555556abc400(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fda689c3303 CR3: 000000001cfbb000 CR4: 0000000000350ef0
Call Trace:
&lt;TASK&gt;
tcf_chain0_head_change_cb_del+0x2e/0x3d0 net/sched/cls_api.c:810
tcf_block_put_ext net/sched/cls_api.c:1381 [inline]
tcf_block_put_ext net/sched/cls_api.c:1376 [inline]
tcf_block_put+0xbc/0x130 net/sched/cls_api.c:1394
cake_destroy+0x3f/0x80 net/sched/sch_cake.c:2695
qdisc_create.constprop.0+0x9da/0x10f0 net/sched/sch_api.c:1293
tc_modify_qdisc+0x4c5/0x1980 net/sched/sch_api.c:1660
rtnetlink_rcv_msg+0x413/0xb80 net/core/rtnetlink.c:5571
netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2496
netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1345
netlink_sendmsg+0x904/0xdf0 net/netlink/af_netlink.c:1921
sock_sendmsg_nosec net/socket.c:704 [inline]
sock_sendmsg+0xcf/0x120 net/socket.c:724
____sys_sendmsg+0x6e8/0x810 net/socket.c:2409
___sys_sendmsg+0xf3/0x170 net/socket.c:2463
__sys_sendmsg+0xe5/0x1b0 net/socket.c:2492
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f1bb06badb9
Code: Unable to access opcode bytes at RIP 0x7f1bb06bad8f.
RSP: 002b:00007fff3012a658 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f1bb06badb9
RDX: 0000000000000000 RSI: 00000000200007c0 RDI: 0000000000000003
RBP: 0000000000000000 R08: 0000000000000003 R09: 0000000000000003
R10: 0000000000000003 R11: 0000000000000246 R12: 00007fff3012a688
R13: 00007fff3012a6a0 R14: 00007fff3012a6e0 R15: 00000000000013c2
&lt;/TASK&gt;</Note>
</Notes>
<ReleaseDate>2024-07-19</ReleaseDate>
<CVE>CVE-2021-47598</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>Low</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-19</DATE>
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1862</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:
drm/nouveau: fix off by one in BIOS boundary checking
Bounds checking when parsing init scripts embedded in the BIOS reject
access to the last byte. This causes driver initialization to fail on
Apple eMac&apos;s with GeForce 2 MX GPUs, leaving the system with no working
console.
This is probably only seen on OpenFirmware machines like PowerPC Macs
because the BIOS image provided by OF is only the used parts of the ROM,
not a power-of-two blocks read from PCI directly so PCs always have
empty bytes at the end that are never accessed.</Note>
</Notes>
<ReleaseDate>2024-07-19</ReleaseDate>
<CVE>CVE-2022-48732</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-20.03-LTS-SP4</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-19</DATE>
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1862</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:
net: fix information leakage in /proc/net/ptype
In one net namespace, after creating a packet socket without binding
it to a device, users in other net namespaces can observe the new
`packet_type` added by this packet socket by reading `/proc/net/ptype`
file. This is minor information leakage as packet socket is
namespace aware.
Add a net pointer in `packet_type` to keep the net namespace of
of corresponding packet socket. In `ptype_seq_show`, this net pointer
must be checked when it is not NULL.</Note>
</Notes>
<ReleaseDate>2024-07-19</ReleaseDate>
<CVE>CVE-2022-48757</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-20.03-LTS-SP4</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-19</DATE>
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1862</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:
USB: core: Fix hang in usb_kill_urb by adding memory barriers
The syzbot fuzzer has identified a bug in which processes hang waiting
for usb_kill_urb() to return. It turns out the issue is not unlinking
the URB; that works just fine. Rather, the problem arises when the
wakeup notification that the URB has completed is not received.
The reason is memory-access ordering on SMP systems. In outline form,
usb_kill_urb() and __usb_hcd_giveback_urb() operating concurrently on
different CPUs perform the following actions:
CPU 0 CPU 1
---------------------------- ---------------------------------
usb_kill_urb(): __usb_hcd_giveback_urb():
... ...
atomic_inc(&amp;urb-&gt;reject); atomic_dec(&amp;urb-&gt;use_count);
... ...
wait_event(usb_kill_urb_queue,
atomic_read(&amp;urb-&gt;use_count) == 0);
if (atomic_read(&amp;urb-&gt;reject))
wake_up(&amp;usb_kill_urb_queue);
Confining your attention to urb-&gt;reject and urb-&gt;use_count, you can
see that the overall pattern of accesses on CPU 0 is:
write urb-&gt;reject, then read urb-&gt;use_count;
whereas the overall pattern of accesses on CPU 1 is:
write urb-&gt;use_count, then read urb-&gt;reject.
This pattern is referred to in memory-model circles as SB (for &quot;Store
Buffering&quot;), and it is well known that without suitable enforcement of
the desired order of accesses -- in the form of memory barriers -- it
is entirely possible for one or both CPUs to execute their reads ahead
of their writes. The end result will be that sometimes CPU 0 sees the
old un-decremented value of urb-&gt;use_count while CPU 1 sees the old
un-incremented value of urb-&gt;reject. Consequently CPU 0 ends up on
the wait queue and never gets woken up, leading to the observed hang
in usb_kill_urb().
The same pattern of accesses occurs in usb_poison_urb() and the
failure pathway of usb_hcd_submit_urb().
The problem is fixed by adding suitable memory barriers. To provide
proper memory-access ordering in the SB pattern, a full barrier is
required on both CPUs. The atomic_inc() and atomic_dec() accesses
themselves don&apos;t provide any memory ordering, but since they are
present, we can use the optimized smp_mb__after_atomic() memory
barrier in the various routines to obtain the desired effect.
This patch adds the necessary memory barriers.</Note>
</Notes>
<ReleaseDate>2024-07-19</ReleaseDate>
<CVE>CVE-2022-48760</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-20.03-LTS-SP4</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-19</DATE>
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1862</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:
net: openvswitch: fix overwriting ct original tuple for ICMPv6
OVS_PACKET_CMD_EXECUTE has 3 main attributes:
- OVS_PACKET_ATTR_KEY - Packet metadata in a netlink format.
- OVS_PACKET_ATTR_PACKET - Binary packet content.
- OVS_PACKET_ATTR_ACTIONS - Actions to execute on the packet.
OVS_PACKET_ATTR_KEY is parsed first to populate sw_flow_key structure
with the metadata like conntrack state, input port, recirculation id,
etc. Then the packet itself gets parsed to populate the rest of the
keys from the packet headers.
Whenever the packet parsing code starts parsing the ICMPv6 header, it
first zeroes out fields in the key corresponding to Neighbor Discovery
information even if it is not an ND packet.
It is an &apos;ipv6.nd&apos; field. However, the &apos;ipv6&apos; is a union that shares
the space between &apos;nd&apos; and &apos;ct_orig&apos; that holds the original tuple
conntrack metadata parsed from the OVS_PACKET_ATTR_KEY.
ND packets should not normally have conntrack state, so it&apos;s fine to
share the space, but normal ICMPv6 Echo packets or maybe other types of
ICMPv6 can have the state attached and it should not be overwritten.
The issue results in all but the last 4 bytes of the destination
address being wiped from the original conntrack tuple leading to
incorrect packet matching and potentially executing wrong actions
in case this packet recirculates within the datapath or goes back
to userspace.
ND fields should not be accessed in non-ND packets, so not clearing
them should be fine. Executing memset() only for actual ND packets to
avoid the issue.
Initializing the whole thing before parsing is needed because ND packet
may not contain all the options.
The issue only affects the OVS_PACKET_CMD_EXECUTE path and doesn&apos;t
affect packets entering OVS datapath from network interfaces, because
in this case CT metadata is populated from skb after the packet is
already parsed.</Note>
</Notes>
<ReleaseDate>2024-07-19</ReleaseDate>
<CVE>CVE-2024-38558</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-20.03-LTS-SP4</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-19</DATE>
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1862</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:
vfio/pci: fix potential memory leak in vfio_intx_enable()
If vfio_irq_ctx_alloc() failed will lead to &apos;name&apos; memory leak.</Note>
</Notes>
<ReleaseDate>2024-07-19</ReleaseDate>
<CVE>CVE-2024-38632</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-20.03-LTS-SP4</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-19</DATE>
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1862</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:kdb: Fix buffer overflow during tab-completeCurrently, when the user attempts symbol completion with the Tab key, kdbwill use strncpy() to insert the completed symbol into the command buffer.Unfortunately it passes the size of the source buffer rather than thedestination to strncpy() with predictably horrible results. Most obviouslyif the command buffer is already full but cp, the cursor position, is inthe middle of the buffer, then we will write past the end of the suppliedbuffer.Fix this by replacing the dubious strncpy() calls with memmove()/memcpy()calls plus explicit boundary checks to make sure we have enough spacebefore we start moving characters around.</Note>
</Notes>
<ReleaseDate>2024-07-19</ReleaseDate>
<CVE>CVE-2024-39480</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-20.03-LTS-SP4</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-19</DATE>
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1862</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:
bonding: Fix out-of-bounds read in bond_option_arp_ip_targets_set()
In function bond_option_arp_ip_targets_set(), if newval-&gt;string is an
empty string, newval-&gt;string+1 will point to the byte after the
string, causing an out-of-bound read.
BUG: KASAN: slab-out-of-bounds in strlen+0x7d/0xa0 lib/string.c:418
Read of size 1 at addr ffff8881119c4781 by task syz-executor665/8107
CPU: 1 PID: 8107 Comm: syz-executor665 Not tainted 6.7.0-rc7 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Call Trace:
&lt;TASK&gt;
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106
print_address_description mm/kasan/report.c:364 [inline]
print_report+0xc1/0x5e0 mm/kasan/report.c:475
kasan_report+0xbe/0xf0 mm/kasan/report.c:588
strlen+0x7d/0xa0 lib/string.c:418
__fortify_strlen include/linux/fortify-string.h:210 [inline]
in4_pton+0xa3/0x3f0 net/core/utils.c:130
bond_option_arp_ip_targets_set+0xc2/0x910
drivers/net/bonding/bond_options.c:1201
__bond_opt_set+0x2a4/0x1030 drivers/net/bonding/bond_options.c:767
__bond_opt_set_notify+0x48/0x150 drivers/net/bonding/bond_options.c:792
bond_opt_tryset_rtnl+0xda/0x160 drivers/net/bonding/bond_options.c:817
bonding_sysfs_store_option+0xa1/0x120 drivers/net/bonding/bond_sysfs.c:156
dev_attr_store+0x54/0x80 drivers/base/core.c:2366
sysfs_kf_write+0x114/0x170 fs/sysfs/file.c:136
kernfs_fop_write_iter+0x337/0x500 fs/kernfs/file.c:334
call_write_iter include/linux/fs.h:2020 [inline]
new_sync_write fs/read_write.c:491 [inline]
vfs_write+0x96a/0xd80 fs/read_write.c:584
ksys_write+0x122/0x250 fs/read_write.c:637
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
---[ end trace ]---
Fix it by adding a check of string length before using it.</Note>
</Notes>
<ReleaseDate>2024-07-19</ReleaseDate>
<CVE>CVE-2024-39487</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-20.03-LTS-SP4</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-19</DATE>
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1862</URL>
</Remediation>
</Remediations>
</Vulnerability>
<Vulnerability Ordinal="12" 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:
arm64: asm-bug: Add .align 2 to the end of __BUG_ENTRY
When CONFIG_DEBUG_BUGVERBOSE=n, we fail to add necessary padding bytes
to bug_table entries, and as a result the last entry in a bug table will
be ignored, potentially leading to an unexpected panic(). All prior
entries in the table will be handled correctly.
The arm64 ABI requires that struct fields of up to 8 bytes are
naturally-aligned, with padding added within a struct such that struct
are suitably aligned within arrays.
When CONFIG_DEBUG_BUGVERPOSE=y, the layout of a bug_entry is:
struct bug_entry {
signed int bug_addr_disp; // 4 bytes
signed int file_disp; // 4 bytes
unsigned short line; // 2 bytes
unsigned short flags; // 2 bytes
}
... with 12 bytes total, requiring 4-byte alignment.
When CONFIG_DEBUG_BUGVERBOSE=n, the layout of a bug_entry is:
struct bug_entry {
signed int bug_addr_disp; // 4 bytes
unsigned short flags; // 2 bytes
&lt; implicit padding &gt; // 2 bytes
}
... with 8 bytes total, with 6 bytes of data and 2 bytes of trailing
padding, requiring 4-byte alginment.
When we create a bug_entry in assembly, we align the start of the entry
to 4 bytes, which implicitly handles padding for any prior entries.
However, we do not align the end of the entry, and so when
CONFIG_DEBUG_BUGVERBOSE=n, the final entry lacks the trailing padding
bytes.
For the main kernel image this is not a problem as find_bug() doesn&apos;t
depend on the trailing padding bytes when searching for entries:
for (bug = __start___bug_table; bug &lt; __stop___bug_table; ++bug)
if (bugaddr == bug_addr(bug))
return bug;
However for modules, module_bug_finalize() depends on the trailing
bytes when calculating the number of entries:
mod-&gt;num_bugs = sechdrs[i].sh_size / sizeof(struct bug_entry);
... and as the last bug_entry lacks the necessary padding bytes, this entry
will not be counted, e.g. in the case of a single entry:
sechdrs[i].sh_size == 6
sizeof(struct bug_entry) == 8;
sechdrs[i].sh_size / sizeof(struct bug_entry) == 0;
Consequently module_find_bug() will miss the last bug_entry when it does:
for (i = 0; i &lt; mod-&gt;num_bugs; ++i, ++bug)
if (bugaddr == bug_addr(bug))
goto out;
... which can lead to a kenrel panic due to an unhandled bug.
This can be demonstrated with the following module:
static int __init buginit(void)
{
WARN(1, &quot;hello\n&quot;);
return 0;
}
static void __exit bugexit(void)
{
}
module_init(buginit);
module_exit(bugexit);
MODULE_LICENSE(&quot;GPL&quot;);
... which will trigger a kernel panic when loaded:
------------[ cut here ]------------
hello
Unexpected kernel BRK exception at EL1
Internal error: BRK handler: 00000000f2000800 [#1] PREEMPT SMP
Modules linked in: hello(O+)
CPU: 0 PID: 50 Comm: insmod Tainted: G O 6.9.1 #8
Hardware name: linux,dummy-virt (DT)
pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : buginit+0x18/0x1000 [hello]
lr : buginit+0x18/0x1000 [hello]
sp : ffff800080533ae0
x29: ffff800080533ae0 x28: 0000000000000000 x27: 0000000000000000
x26: ffffaba8c4e70510 x25: ffff800080533c30 x24: ffffaba8c4a28a58
x23: 0000000000000000 x22: 0000000000000000 x21: ffff3947c0eab3c0
x20: ffffaba8c4e3f000 x19: ffffaba846464000 x18: 0000000000000006
x17: 0000000000000000 x16: ffffaba8c2492834 x15: 0720072007200720
x14: 0720072007200720 x13: ffffaba8c49b27c8 x12: 0000000000000312
x11: 0000000000000106 x10: ffffaba8c4a0a7c8 x9 : ffffaba8c49b27c8
x8 : 00000000ffffefff x7 : ffffaba8c4a0a7c8 x6 : 80000000fffff000
x5 : 0000000000000107 x4 : 0000000000000000 x3 : 0000000000000000
x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff3947c0eab3c0
Call trace:
buginit+0x18/0x1000 [hello]
do_one_initcall+0x80/0x1c8
do_init_module+0x60/0x218
load_module+0x1ba4/0x1d70
__do_sys_init_module+0x198/0x1d0
__arm64_sys_init_module+0x1c/0x28
invoke_syscall+0x48/0x114
el0_svc
---truncated---</Note>
</Notes>
<ReleaseDate>2024-07-19</ReleaseDate>
<CVE>CVE-2024-39488</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-20.03-LTS-SP4</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-19</DATE>
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1862</URL>
</Remediation>
</Remediations>
</Vulnerability>
<Vulnerability Ordinal="13" 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:
ipv6: sr: fix memleak in seg6_hmac_init_algo
seg6_hmac_init_algo returns without cleaning up the previous allocations
if one fails, so it&apos;s going to leak all that memory and the crypto tfms.
Update seg6_hmac_exit to only free the memory when allocated, so we can
reuse the code directly.</Note>
</Notes>
<ReleaseDate>2024-07-19</ReleaseDate>
<CVE>CVE-2024-39489</CVE>
<ProductStatuses>
<Status Type="Fixed">
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
</Status>
</ProductStatuses>
<Threats>
<Threat Type="Impact">
<Description>Low</Description>
</Threat>
</Threats>
<CVSSScoreSets>
<ScoreSet>
<BaseScore>3.3</BaseScore>
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L</Vector>
</ScoreSet>
</CVSSScoreSets>
<Remediations>
<Remediation Type="Vendor Fix">
<Description>kernel security update</Description>
<DATE>2024-07-19</DATE>
<URL>https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1862</URL>
</Remediation>
</Remediations>
</Vulnerability>
</cvrfdoc>
Reference in New Issue View Git Blame Copy Permalink