2231 lines
99 KiB
XML
2231 lines
99 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<cvrfdoc xmlns="http://www.icasi.org/CVRF/schema/cvrf/1.1" xmlns:cvrf="http://www.icasi.org/CVRF/schema/cvrf/1.1">
|
|
<DocumentTitle xml:lang="en">An update for kernel is now available for openEuler-22.03-LTS-SP3</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-1482</ID>
|
|
</Identification>
|
|
<Status>Final</Status>
|
|
<Version>1.0</Version>
|
|
<RevisionHistory>
|
|
<Revision>
|
|
<Number>1.0</Number>
|
|
<Date>2024-04-19</Date>
|
|
<Description>Initial</Description>
|
|
</Revision>
|
|
</RevisionHistory>
|
|
<InitialReleaseDate>2024-04-19</InitialReleaseDate>
|
|
<CurrentReleaseDate>2024-04-19</CurrentReleaseDate>
|
|
<Generator>
|
|
<Engine>openEuler SA Tool V1.0</Engine>
|
|
<Date>2024-04-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-22.03-LTS-SP3.</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:
|
|
|
|
ALSA: hda: intel-sdw-acpi: harden detection of controller
|
|
|
|
The existing code currently sets a pointer to an ACPI handle before
|
|
checking that it's actually a SoundWire controller. This can lead to
|
|
issues where the graph walk continues and eventually fails, but the
|
|
pointer was set already.
|
|
|
|
This patch changes the logic so that the information provided to
|
|
the caller is set when a controller is found.(CVE-2021-46926)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
uio_hv_generic: Fix another memory leak in error handling paths
|
|
|
|
Memory allocated by 'vmbus_alloc_ring()' at the beginning of the probe
|
|
function is never freed in the error handling path.
|
|
|
|
Add the missing 'vmbus_free_ring()' call.
|
|
|
|
Note that it is already freed in the .remove function.(CVE-2021-47070)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
asix: fix uninit-value in asix_mdio_read()
|
|
|
|
asix_read_cmd() may read less than sizeof(smsr) bytes and in this case
|
|
smsr will be uninitialized.
|
|
|
|
Fail log:
|
|
BUG: KMSAN: uninit-value in asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline]
|
|
BUG: KMSAN: uninit-value in asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] drivers/net/usb/asix_common.c:497
|
|
BUG: KMSAN: uninit-value in asix_mdio_read+0x3c1/0xb00 drivers/net/usb/asix_common.c:497 drivers/net/usb/asix_common.c:497
|
|
asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline]
|
|
asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] drivers/net/usb/asix_common.c:497
|
|
asix_mdio_read+0x3c1/0xb00 drivers/net/usb/asix_common.c:497 drivers/net/usb/asix_common.c:497(CVE-2021-47101)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
EDAC/thunderx: Fix possible out-of-bounds string access
|
|
|
|
Enabling -Wstringop-overflow globally exposes a warning for a common bug
|
|
in the usage of strncat():
|
|
|
|
drivers/edac/thunderx_edac.c: In function 'thunderx_ocx_com_threaded_isr':
|
|
drivers/edac/thunderx_edac.c:1136:17: error: 'strncat' specified bound 1024 equals destination size [-Werror=stringop-overflow=]
|
|
1136 | strncat(msg, other, OCX_MESSAGE_SIZE);
|
|
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
...
|
|
1145 | strncat(msg, other, OCX_MESSAGE_SIZE);
|
|
...
|
|
1150 | strncat(msg, other, OCX_MESSAGE_SIZE);
|
|
|
|
...
|
|
|
|
Apparently the author of this driver expected strncat() to behave the
|
|
way that strlcat() does, which uses the size of the destination buffer
|
|
as its third argument rather than the length of the source buffer. The
|
|
result is that there is no check on the size of the allocated buffer.
|
|
|
|
Change it to strlcat().
|
|
|
|
[ bp: Trim compiler output, fixup commit message. ](CVE-2023-52464)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
Input: powermate - fix use-after-free in powermate_config_complete
|
|
|
|
syzbot has found a use-after-free bug [1] in the powermate driver. This
|
|
happens when the device is disconnected, which leads to a memory free from
|
|
the powermate_device struct. When an asynchronous control message
|
|
completes after the kfree and its callback is invoked, the lock does not
|
|
exist anymore and hence the bug.
|
|
|
|
Use usb_kill_urb() on pm->config to cancel any in-progress requests upon
|
|
device disconnection.
|
|
|
|
[1] https://syzkaller.appspot.com/bug?extid=0434ac83f907a1dbdd1e(CVE-2023-52475)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
scsi: pm80xx: Avoid leaking tags when processing OPC_INB_SET_CONTROLLER_CONFIG command
|
|
|
|
Tags allocated for OPC_INB_SET_CONTROLLER_CONFIG command need to be freed
|
|
when we receive the response.(CVE-2023-52500)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
nfc: nci: assert requested protocol is valid
|
|
|
|
The protocol is used in a bit mask to determine if the protocol is
|
|
supported. Assert the provided protocol is less than the maximum
|
|
defined so it doesn't potentially perform a shift-out-of-bounds and
|
|
provide a clearer error for undefined protocols vs unsupported ones.(CVE-2023-52507)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ieee802154: ca8210: Fix a potential UAF in ca8210_probe
|
|
|
|
If of_clk_add_provider() fails in ca8210_register_ext_clock(),
|
|
it calls clk_unregister() to release priv->clk and returns an
|
|
error. However, the caller ca8210_probe() then calls ca8210_remove(),
|
|
where priv->clk is freed again in ca8210_unregister_ext_clock(). In
|
|
this case, a use-after-free may happen in the second time we call
|
|
clk_unregister().
|
|
|
|
Fix this by removing the first clk_unregister(). Also, priv->clk could
|
|
be an error code on failure of clk_register_fixed_rate(). Use
|
|
IS_ERR_OR_NULL to catch this case in ca8210_unregister_ext_clock().(CVE-2023-52510)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
RDMA/srp: Do not call scsi_done() from srp_abort()
|
|
|
|
After scmd_eh_abort_handler() has called the SCSI LLD eh_abort_handler
|
|
callback, it performs one of the following actions:
|
|
* Call scsi_queue_insert().
|
|
* Call scsi_finish_command().
|
|
* Call scsi_eh_scmd_add().
|
|
Hence, SCSI abort handlers must not call scsi_done(). Otherwise all
|
|
the above actions would trigger a use-after-free. Hence remove the
|
|
scsi_done() call from srp_abort(). Keep the srp_free_req() call
|
|
before returning SUCCESS because we may not see the command again if
|
|
SUCCESS is returned.(CVE-2023-52515)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: fix possible store tearing in neigh_periodic_work()
|
|
|
|
While looking at a related syzbot report involving neigh_periodic_work(),
|
|
I found that I forgot to add an annotation when deleting an
|
|
RCU protected item from a list.
|
|
|
|
Readers use rcu_deference(*np), we need to use either
|
|
rcu_assign_pointer() or WRITE_ONCE() on writer side
|
|
to prevent store tearing.
|
|
|
|
I use rcu_assign_pointer() to have lockdep support,
|
|
this was the choice made in neigh_flush_dev().(CVE-2023-52522)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: mwifiex: Fix oob check condition in mwifiex_process_rx_packet
|
|
|
|
Only skip the code path trying to access the rfc1042 headers when the
|
|
buffer is too small, so the driver can still process packets without
|
|
rfc1042 headers.(CVE-2023-52525)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: mac80211: fix potential key use-after-free
|
|
|
|
When ieee80211_key_link() is called by ieee80211_gtk_rekey_add()
|
|
but returns 0 due to KRACK protection (identical key reinstall),
|
|
ieee80211_gtk_rekey_add() will still return a pointer into the
|
|
key, in a potential use-after-free. This normally doesn't happen
|
|
since it's only called by iwlwifi in case of WoWLAN rekey offload
|
|
which has its own KRACK protection, but still better to fix, do
|
|
that by returning an error code and converting that to success on
|
|
the cfg80211 boundary only, leaving the error for bad callers of
|
|
ieee80211_gtk_rekey_add().(CVE-2023-52530)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
mm/damon/vaddr-test: fix memory leak in damon_do_test_apply_three_regions()
|
|
|
|
When CONFIG_DAMON_VADDR_KUNIT_TEST=y and making CONFIG_DEBUG_KMEMLEAK=y
|
|
and CONFIG_DEBUG_KMEMLEAK_AUTO_SCAN=y, the below memory leak is detected.
|
|
|
|
Since commit 9f86d624292c ("mm/damon/vaddr-test: remove unnecessary
|
|
variables"), the damon_destroy_ctx() is removed, but still call
|
|
damon_new_target() and damon_new_region(), the damon_region which is
|
|
allocated by kmem_cache_alloc() in damon_new_region() and the damon_target
|
|
which is allocated by kmalloc in damon_new_target() are not freed. And
|
|
the damon_region which is allocated in damon_new_region() in
|
|
damon_set_regions() is also not freed.
|
|
|
|
So use damon_destroy_target to free all the damon_regions and damon_target.
|
|
|
|
unreferenced object 0xffff888107c9a940 (size 64):
|
|
comm "kunit_try_catch", pid 1069, jiffies 4294670592 (age 732.761s)
|
|
hex dump (first 32 bytes):
|
|
00 00 00 00 00 00 00 00 06 00 00 00 6b 6b 6b 6b ............kkkk
|
|
60 c7 9c 07 81 88 ff ff f8 cb 9c 07 81 88 ff ff `...............
|
|
backtrace:
|
|
[<ffffffff817e0167>] kmalloc_trace+0x27/0xa0
|
|
[<ffffffff819c11cf>] damon_new_target+0x3f/0x1b0
|
|
[<ffffffff819c7d55>] damon_do_test_apply_three_regions.constprop.0+0x95/0x3e0
|
|
[<ffffffff819c82be>] damon_test_apply_three_regions1+0x21e/0x260
|
|
[<ffffffff829fce6a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
|
|
[<ffffffff81237cf6>] kthread+0x2b6/0x380
|
|
[<ffffffff81097add>] ret_from_fork+0x2d/0x70
|
|
[<ffffffff81003791>] ret_from_fork_asm+0x11/0x20
|
|
unreferenced object 0xffff8881079cc740 (size 56):
|
|
comm "kunit_try_catch", pid 1069, jiffies 4294670592 (age 732.761s)
|
|
hex dump (first 32 bytes):
|
|
05 00 00 00 00 00 00 00 14 00 00 00 00 00 00 00 ................
|
|
6b 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 6b 6b 6b 6b kkkkkkkk....kkkk
|
|
backtrace:
|
|
[<ffffffff819bc492>] damon_new_region+0x22/0x1c0
|
|
[<ffffffff819c7d91>] damon_do_test_apply_three_regions.constprop.0+0xd1/0x3e0
|
|
[<ffffffff819c82be>] damon_test_apply_three_regions1+0x21e/0x260
|
|
[<ffffffff829fce6a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
|
|
[<ffffffff81237cf6>] kthread+0x2b6/0x380
|
|
[<ffffffff81097add>] ret_from_fork+0x2d/0x70
|
|
[<ffffffff81003791>] ret_from_fork_asm+0x11/0x20
|
|
unreferenced object 0xffff888107c9ac40 (size 64):
|
|
comm "kunit_try_catch", pid 1071, jiffies 4294670595 (age 732.843s)
|
|
hex dump (first 32 bytes):
|
|
00 00 00 00 00 00 00 00 06 00 00 00 6b 6b 6b 6b ............kkkk
|
|
a0 cc 9c 07 81 88 ff ff 78 a1 76 07 81 88 ff ff ........x.v.....
|
|
backtrace:
|
|
[<ffffffff817e0167>] kmalloc_trace+0x27/0xa0
|
|
[<ffffffff819c11cf>] damon_new_target+0x3f/0x1b0
|
|
[<ffffffff819c7d55>] damon_do_test_apply_three_regions.constprop.0+0x95/0x3e0
|
|
[<ffffffff819c851e>] damon_test_apply_three_regions2+0x21e/0x260
|
|
[<ffffffff829fce6a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
|
|
[<ffffffff81237cf6>] kthread+0x2b6/0x380
|
|
[<ffffffff81097add>] ret_from_fork+0x2d/0x70
|
|
[<ffffffff81003791>] ret_from_fork_asm+0x11/0x20
|
|
unreferenced object 0xffff8881079ccc80 (size 56):
|
|
comm "kunit_try_catch", pid 1071, jiffies 4294670595 (age 732.843s)
|
|
hex dump (first 32 bytes):
|
|
05 00 00 00 00 00 00 00 14 00 00 00 00 00 00 00 ................
|
|
6b 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 6b 6b 6b 6b kkkkkkkk....kkkk
|
|
backtrace:
|
|
[<ffffffff819bc492>] damon_new_region+0x22/0x1c0
|
|
[<ffffffff819c7d91>] damon_do_test_apply_three_regions.constprop.0+0xd1/0x3e0
|
|
[<ffffffff819c851e>] damon_test_apply_three_regions2+0x21e/0x260
|
|
[<ffffffff829fce6a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
|
|
[<ffffffff81237cf6>] kthread+0x2b6/0x380
|
|
[<ffffffff81097add>] ret_from_fork+0x2d/0x70
|
|
[<ffff
|
|
---truncated---(CVE-2023-52560)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
arm64: dts: qcom: sdm845-db845c: Mark cont splash memory region as reserved
|
|
|
|
Adding a reserved memory region for the framebuffer memory
|
|
(the splash memory region set up by the bootloader).
|
|
|
|
It fixes a kernel panic (arm-smmu: Unhandled context fault
|
|
at this particular memory region) reported on DB845c running
|
|
v5.10.y.(CVE-2023-52561)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
nilfs2: fix potential use after free in nilfs_gccache_submit_read_data()
|
|
|
|
In nilfs_gccache_submit_read_data(), brelse(bh) is called to drop the
|
|
reference count of bh when the call to nilfs_dat_translate() fails. If
|
|
the reference count hits 0 and its owner page gets unlocked, bh may be
|
|
freed. However, bh->b_page is dereferenced to put the page after that,
|
|
which may result in a use-after-free bug. This patch moves the release
|
|
operation after unlocking and putting the page.
|
|
|
|
NOTE: The function in question is only called in GC, and in combination
|
|
with current userland tools, address translation using DAT does not occur
|
|
in that function, so the code path that causes this issue will not be
|
|
executed. However, it is possible to run that code path by intentionally
|
|
modifying the userland GC library or by calling the GC ioctl directly.
|
|
|
|
[konishi.ryusuke@gmail.com: NOTE added to the commit log](CVE-2023-52566)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
x86/sgx: Resolves SECS reclaim vs. page fault for EAUG race
|
|
|
|
The SGX EPC reclaimer (ksgxd) may reclaim the SECS EPC page for an
|
|
enclave and set secs.epc_page to NULL. The SECS page is used for EAUG
|
|
and ELDU in the SGX page fault handler. However, the NULL check for
|
|
secs.epc_page is only done for ELDU, not EAUG before being used.
|
|
|
|
Fix this by doing the same NULL check and reloading of the SECS page as
|
|
needed for both EAUG and ELDU.
|
|
|
|
The SECS page holds global enclave metadata. It can only be reclaimed
|
|
when there are no other enclave pages remaining. At that point,
|
|
virtually nothing can be done with the enclave until the SECS page is
|
|
paged back in.
|
|
|
|
An enclave can not run nor generate page faults without a resident SECS
|
|
page. But it is still possible for a #PF for a non-SECS page to race
|
|
with paging out the SECS page: when the last resident non-SECS page A
|
|
triggers a #PF in a non-resident page B, and then page A and the SECS
|
|
both are paged out before the #PF on B is handled.
|
|
|
|
Hitting this bug requires that race triggered with a #PF for EAUG.
|
|
Following is a trace when it happens.
|
|
|
|
BUG: kernel NULL pointer dereference, address: 0000000000000000
|
|
RIP: 0010:sgx_encl_eaug_page+0xc7/0x210
|
|
Call Trace:
|
|
? __kmem_cache_alloc_node+0x16a/0x440
|
|
? xa_load+0x6e/0xa0
|
|
sgx_vma_fault+0x119/0x230
|
|
__do_fault+0x36/0x140
|
|
do_fault+0x12f/0x400
|
|
__handle_mm_fault+0x728/0x1110
|
|
handle_mm_fault+0x105/0x310
|
|
do_user_addr_fault+0x1ee/0x750
|
|
? __this_cpu_preempt_check+0x13/0x20
|
|
exc_page_fault+0x76/0x180
|
|
asm_exc_page_fault+0x27/0x30(CVE-2023-52568)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: rds: Fix possible NULL-pointer dereference
|
|
|
|
In rds_rdma_cm_event_handler_cmn() check, if conn pointer exists
|
|
before dereferencing it as rdma_set_service_type() argument
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2023-52573)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
dccp: fix dccp_v4_err()/dccp_v6_err() again
|
|
|
|
dh->dccph_x is the 9th byte (offset 8) in "struct dccp_hdr",
|
|
not in the "byte 7" as Jann claimed.
|
|
|
|
We need to make sure the ICMP messages are big enough,
|
|
using more standard ways (no more assumptions).
|
|
|
|
syzbot reported:
|
|
BUG: KMSAN: uninit-value in pskb_may_pull_reason include/linux/skbuff.h:2667 [inline]
|
|
BUG: KMSAN: uninit-value in pskb_may_pull include/linux/skbuff.h:2681 [inline]
|
|
BUG: KMSAN: uninit-value in dccp_v6_err+0x426/0x1aa0 net/dccp/ipv6.c:94
|
|
pskb_may_pull_reason include/linux/skbuff.h:2667 [inline]
|
|
pskb_may_pull include/linux/skbuff.h:2681 [inline]
|
|
dccp_v6_err+0x426/0x1aa0 net/dccp/ipv6.c:94
|
|
icmpv6_notify+0x4c7/0x880 net/ipv6/icmp.c:867
|
|
icmpv6_rcv+0x19d5/0x30d0
|
|
ip6_protocol_deliver_rcu+0xda6/0x2a60 net/ipv6/ip6_input.c:438
|
|
ip6_input_finish net/ipv6/ip6_input.c:483 [inline]
|
|
NF_HOOK include/linux/netfilter.h:304 [inline]
|
|
ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492
|
|
ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586
|
|
dst_input include/net/dst.h:468 [inline]
|
|
ip6_rcv_finish+0x5db/0x870 net/ipv6/ip6_input.c:79
|
|
NF_HOOK include/linux/netfilter.h:304 [inline]
|
|
ipv6_rcv+0xda/0x390 net/ipv6/ip6_input.c:310
|
|
__netif_receive_skb_one_core net/core/dev.c:5523 [inline]
|
|
__netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5637
|
|
netif_receive_skb_internal net/core/dev.c:5723 [inline]
|
|
netif_receive_skb+0x58/0x660 net/core/dev.c:5782
|
|
tun_rx_batched+0x83b/0x920
|
|
tun_get_user+0x564c/0x6940 drivers/net/tun.c:2002
|
|
tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048
|
|
call_write_iter include/linux/fs.h:1985 [inline]
|
|
new_sync_write fs/read_write.c:491 [inline]
|
|
vfs_write+0x8ef/0x15c0 fs/read_write.c:584
|
|
ksys_write+0x20f/0x4c0 fs/read_write.c:637
|
|
__do_sys_write fs/read_write.c:649 [inline]
|
|
__se_sys_write fs/read_write.c:646 [inline]
|
|
__x64_sys_write+0x93/0xd0 fs/read_write.c:646
|
|
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
|
|
do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
|
|
entry_SYSCALL_64_after_hwframe+0x63/0xcd
|
|
|
|
Uninit was created at:
|
|
slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767
|
|
slab_alloc_node mm/slub.c:3478 [inline]
|
|
kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523
|
|
kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:559
|
|
__alloc_skb+0x318/0x740 net/core/skbuff.c:650
|
|
alloc_skb include/linux/skbuff.h:1286 [inline]
|
|
alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6313
|
|
sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2795
|
|
tun_alloc_skb drivers/net/tun.c:1531 [inline]
|
|
tun_get_user+0x23cf/0x6940 drivers/net/tun.c:1846
|
|
tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048
|
|
call_write_iter include/linux/fs.h:1985 [inline]
|
|
new_sync_write fs/read_write.c:491 [inline]
|
|
vfs_write+0x8ef/0x15c0 fs/read_write.c:584
|
|
ksys_write+0x20f/0x4c0 fs/read_write.c:637
|
|
__do_sys_write fs/read_write.c:649 [inline]
|
|
__se_sys_write fs/read_write.c:646 [inline]
|
|
__x64_sys_write+0x93/0xd0 fs/read_write.c:646
|
|
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
|
|
do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
|
|
entry_SYSCALL_64_after_hwframe+0x63/0xcd
|
|
|
|
CPU: 0 PID: 4995 Comm: syz-executor153 Not tainted 6.6.0-rc1-syzkaller-00014-ga747acc0b752 #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023(CVE-2023-52577)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: bridge: use DEV_STATS_INC()
|
|
|
|
syzbot/KCSAN reported data-races in br_handle_frame_finish() [1]
|
|
This function can run from multiple cpus without mutual exclusion.
|
|
|
|
Adopt SMP safe DEV_STATS_INC() to update dev->stats fields.
|
|
|
|
Handles updates to dev->stats.tx_dropped while we are at it.
|
|
|
|
[1]
|
|
BUG: KCSAN: data-race in br_handle_frame_finish / br_handle_frame_finish
|
|
|
|
read-write to 0xffff8881374b2178 of 8 bytes by interrupt on cpu 1:
|
|
br_handle_frame_finish+0xd4f/0xef0 net/bridge/br_input.c:189
|
|
br_nf_hook_thresh+0x1ed/0x220
|
|
br_nf_pre_routing_finish_ipv6+0x50f/0x540
|
|
NF_HOOK include/linux/netfilter.h:304 [inline]
|
|
br_nf_pre_routing_ipv6+0x1e3/0x2a0 net/bridge/br_netfilter_ipv6.c:178
|
|
br_nf_pre_routing+0x526/0xba0 net/bridge/br_netfilter_hooks.c:508
|
|
nf_hook_entry_hookfn include/linux/netfilter.h:144 [inline]
|
|
nf_hook_bridge_pre net/bridge/br_input.c:272 [inline]
|
|
br_handle_frame+0x4c9/0x940 net/bridge/br_input.c:417
|
|
__netif_receive_skb_core+0xa8a/0x21e0 net/core/dev.c:5417
|
|
__netif_receive_skb_one_core net/core/dev.c:5521 [inline]
|
|
__netif_receive_skb+0x57/0x1b0 net/core/dev.c:5637
|
|
process_backlog+0x21f/0x380 net/core/dev.c:5965
|
|
__napi_poll+0x60/0x3b0 net/core/dev.c:6527
|
|
napi_poll net/core/dev.c:6594 [inline]
|
|
net_rx_action+0x32b/0x750 net/core/dev.c:6727
|
|
__do_softirq+0xc1/0x265 kernel/softirq.c:553
|
|
run_ksoftirqd+0x17/0x20 kernel/softirq.c:921
|
|
smpboot_thread_fn+0x30a/0x4a0 kernel/smpboot.c:164
|
|
kthread+0x1d7/0x210 kernel/kthread.c:388
|
|
ret_from_fork+0x48/0x60 arch/x86/kernel/process.c:147
|
|
ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
|
|
|
|
read-write to 0xffff8881374b2178 of 8 bytes by interrupt on cpu 0:
|
|
br_handle_frame_finish+0xd4f/0xef0 net/bridge/br_input.c:189
|
|
br_nf_hook_thresh+0x1ed/0x220
|
|
br_nf_pre_routing_finish_ipv6+0x50f/0x540
|
|
NF_HOOK include/linux/netfilter.h:304 [inline]
|
|
br_nf_pre_routing_ipv6+0x1e3/0x2a0 net/bridge/br_netfilter_ipv6.c:178
|
|
br_nf_pre_routing+0x526/0xba0 net/bridge/br_netfilter_hooks.c:508
|
|
nf_hook_entry_hookfn include/linux/netfilter.h:144 [inline]
|
|
nf_hook_bridge_pre net/bridge/br_input.c:272 [inline]
|
|
br_handle_frame+0x4c9/0x940 net/bridge/br_input.c:417
|
|
__netif_receive_skb_core+0xa8a/0x21e0 net/core/dev.c:5417
|
|
__netif_receive_skb_one_core net/core/dev.c:5521 [inline]
|
|
__netif_receive_skb+0x57/0x1b0 net/core/dev.c:5637
|
|
process_backlog+0x21f/0x380 net/core/dev.c:5965
|
|
__napi_poll+0x60/0x3b0 net/core/dev.c:6527
|
|
napi_poll net/core/dev.c:6594 [inline]
|
|
net_rx_action+0x32b/0x750 net/core/dev.c:6727
|
|
__do_softirq+0xc1/0x265 kernel/softirq.c:553
|
|
do_softirq+0x5e/0x90 kernel/softirq.c:454
|
|
__local_bh_enable_ip+0x64/0x70 kernel/softirq.c:381
|
|
__raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline]
|
|
_raw_spin_unlock_bh+0x36/0x40 kernel/locking/spinlock.c:210
|
|
spin_unlock_bh include/linux/spinlock.h:396 [inline]
|
|
batadv_tt_local_purge+0x1a8/0x1f0 net/batman-adv/translation-table.c:1356
|
|
batadv_tt_purge+0x2b/0x630 net/batman-adv/translation-table.c:3560
|
|
process_one_work kernel/workqueue.c:2630 [inline]
|
|
process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2703
|
|
worker_thread+0x525/0x730 kernel/workqueue.c:2784
|
|
kthread+0x1d7/0x210 kernel/kthread.c:388
|
|
ret_from_fork+0x48/0x60 arch/x86/kernel/process.c:147
|
|
ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
|
|
|
|
value changed: 0x00000000000d7190 -> 0x00000000000d7191
|
|
|
|
Reported by Kernel Concurrency Sanitizer on:
|
|
CPU: 0 PID: 14848 Comm: kworker/u4:11 Not tainted 6.6.0-rc1-syzkaller-00236-gad8a69f361b9 #0(CVE-2023-52578)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ceph: fix deadlock or deadcode of misusing dget()
|
|
|
|
The lock order is incorrect between denty and its parent, we should
|
|
always make sure that the parent get the lock first.
|
|
|
|
But since this deadcode is never used and the parent dir will always
|
|
be set from the callers, let's just remove it.(CVE-2023-52583)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
IB/ipoib: Fix mcast list locking
|
|
|
|
Releasing the `priv->lock` while iterating the `priv->multicast_list` in
|
|
`ipoib_mcast_join_task()` opens a window for `ipoib_mcast_dev_flush()` to
|
|
remove the items while in the middle of iteration. If the mcast is removed
|
|
while the lock was dropped, the for loop spins forever resulting in a hard
|
|
lockup (as was reported on RHEL 4.18.0-372.75.1.el8_6 kernel):
|
|
|
|
Task A (kworker/u72:2 below) | Task B (kworker/u72:0 below)
|
|
-----------------------------------+-----------------------------------
|
|
ipoib_mcast_join_task(work) | ipoib_ib_dev_flush_light(work)
|
|
spin_lock_irq(&priv->lock) | __ipoib_ib_dev_flush(priv, ...)
|
|
list_for_each_entry(mcast, | ipoib_mcast_dev_flush(dev = priv->dev)
|
|
&priv->multicast_list, list) |
|
|
ipoib_mcast_join(dev, mcast) |
|
|
spin_unlock_irq(&priv->lock) |
|
|
| spin_lock_irqsave(&priv->lock, flags)
|
|
| list_for_each_entry_safe(mcast, tmcast,
|
|
| &priv->multicast_list, list)
|
|
| list_del(&mcast->list);
|
|
| list_add_tail(&mcast->list, &remove_list)
|
|
| spin_unlock_irqrestore(&priv->lock, flags)
|
|
spin_lock_irq(&priv->lock) |
|
|
| ipoib_mcast_remove_list(&remove_list)
|
|
(Here, `mcast` is no longer on the | list_for_each_entry_safe(mcast, tmcast,
|
|
`priv->multicast_list` and we keep | remove_list, list)
|
|
spinning on the `remove_list` of | >>> wait_for_completion(&mcast->done)
|
|
the other thread which is blocked |
|
|
and the list is still valid on |
|
|
it's stack.)
|
|
|
|
Fix this by keeping the lock held and changing to GFP_ATOMIC to prevent
|
|
eventual sleeps.
|
|
Unfortunately we could not reproduce the lockup and confirm this fix but
|
|
based on the code review I think this fix should address such lockups.
|
|
|
|
crash> bc 31
|
|
PID: 747 TASK: ff1c6a1a007e8000 CPU: 31 COMMAND: "kworker/u72:2"
|
|
--
|
|
[exception RIP: ipoib_mcast_join_task+0x1b1]
|
|
RIP: ffffffffc0944ac1 RSP: ff646f199a8c7e00 RFLAGS: 00000002
|
|
RAX: 0000000000000000 RBX: ff1c6a1a04dc82f8 RCX: 0000000000000000
|
|
work (&priv->mcast_task{,.work})
|
|
RDX: ff1c6a192d60ac68 RSI: 0000000000000286 RDI: ff1c6a1a04dc8000
|
|
&mcast->list
|
|
RBP: ff646f199a8c7e90 R8: ff1c699980019420 R9: ff1c6a1920c9a000
|
|
R10: ff646f199a8c7e00 R11: ff1c6a191a7d9800 R12: ff1c6a192d60ac00
|
|
mcast
|
|
R13: ff1c6a1d82200000 R14: ff1c6a1a04dc8000 R15: ff1c6a1a04dc82d8
|
|
dev priv (&priv->lock) &priv->multicast_list (aka head)
|
|
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
|
|
--- <NMI exception stack> ---
|
|
#5 [ff646f199a8c7e00] ipoib_mcast_join_task+0x1b1 at ffffffffc0944ac1 [ib_ipoib]
|
|
#6 [ff646f199a8c7e98] process_one_work+0x1a7 at ffffffff9bf10967
|
|
|
|
crash> rx ff646f199a8c7e68
|
|
ff646f199a8c7e68: ff1c6a1a04dc82f8 <<< work = &priv->mcast_task.work
|
|
|
|
crash> list -hO ipoib_dev_priv.multicast_list ff1c6a1a04dc8000
|
|
(empty)
|
|
|
|
crash> ipoib_dev_priv.mcast_task.work.func,mcast_mutex.owner.counter ff1c6a1a04dc8000
|
|
mcast_task.work.func = 0xffffffffc0944910 <ipoib_mcast_join_task>,
|
|
mcast_mutex.owner.counter = 0xff1c69998efec000
|
|
|
|
crash> b 8
|
|
PID: 8 TASK: ff1c69998efec000 CPU: 33 COMMAND: "kworker/u72:0"
|
|
--
|
|
#3 [ff646f1980153d50] wait_for_completion+0x96 at ffffffff9c7d7646
|
|
#4 [ff646f1980153d90] ipoib_mcast_remove_list+0x56 at ffffffffc0944dc6 [ib_ipoib]
|
|
#5 [ff646f1980153de8] ipoib_mcast_dev_flush+0x1a7 at ffffffffc09455a7 [ib_ipoib]
|
|
#6 [ff646f1980153e58] __ipoib_ib_dev_flush+0x1a4 at ffffffffc09431a4 [ib_ipoib]
|
|
#7 [ff
|
|
---truncated---(CVE-2023-52587)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: ath9k: Fix potential array-index-out-of-bounds read in ath9k_htc_txstatus()
|
|
|
|
Fix an array-index-out-of-bounds read in ath9k_htc_txstatus(). The bug
|
|
occurs when txs->cnt, data from a URB provided by a USB device, is
|
|
bigger than the size of the array txs->txstatus, which is
|
|
HTC_MAX_TX_STATUS. WARN_ON() already checks it, but there is no bug
|
|
handling code after the check. Make the function return if that is the
|
|
case.
|
|
|
|
Found by a modified version of syzkaller.
|
|
|
|
UBSAN: array-index-out-of-bounds in htc_drv_txrx.c
|
|
index 13 is out of range for type '__wmi_event_txstatus [12]'
|
|
Call Trace:
|
|
ath9k_htc_txstatus
|
|
ath9k_wmi_event_tasklet
|
|
tasklet_action_common
|
|
__do_softirq
|
|
irq_exit_rxu
|
|
sysvec_apic_timer_interrupt(CVE-2023-52594)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: rt2x00: restart beacon queue when hardware reset
|
|
|
|
When a hardware reset is triggered, all registers are reset, so all
|
|
queues are forced to stop in hardware interface. However, mac80211
|
|
will not automatically stop the queue. If we don't manually stop the
|
|
beacon queue, the queue will be deadlocked and unable to start again.
|
|
This patch fixes the issue where Apple devices cannot connect to the
|
|
AP after calling ieee80211_restart_hw().(CVE-2023-52595)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
KVM: s390: fix setting of fpc register
|
|
|
|
kvm_arch_vcpu_ioctl_set_fpu() allows to set the floating point control
|
|
(fpc) register of a guest cpu. The new value is tested for validity by
|
|
temporarily loading it into the fpc register.
|
|
|
|
This may lead to corruption of the fpc register of the host process:
|
|
if an interrupt happens while the value is temporarily loaded into the fpc
|
|
register, and within interrupt context floating point or vector registers
|
|
are used, the current fp/vx registers are saved with save_fpu_regs()
|
|
assuming they belong to user space and will be loaded into fp/vx registers
|
|
when returning to user space.
|
|
|
|
test_fp_ctl() restores the original user space / host process fpc register
|
|
value, however it will be discarded, when returning to user space.
|
|
|
|
In result the host process will incorrectly continue to run with the value
|
|
that was supposed to be used for a guest cpu.
|
|
|
|
Fix this by simply removing the test. There is another test right before
|
|
the SIE context is entered which will handles invalid values.
|
|
|
|
This results in a change of behaviour: invalid values will now be accepted
|
|
instead of that the ioctl fails with -EINVAL. This seems to be acceptable,
|
|
given that this interface is most likely not used anymore, and this is in
|
|
addition the same behaviour implemented with the memory mapped interface
|
|
(replace invalid values with zero) - see sync_regs() in kvm-s390.c.(CVE-2023-52597)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
s390/ptrace: handle setting of fpc register correctly
|
|
|
|
If the content of the floating point control (fpc) register of a traced
|
|
process is modified with the ptrace interface the new value is tested for
|
|
validity by temporarily loading it into the fpc register.
|
|
|
|
This may lead to corruption of the fpc register of the tracing process:
|
|
if an interrupt happens while the value is temporarily loaded into the
|
|
fpc register, and within interrupt context floating point or vector
|
|
registers are used, the current fp/vx registers are saved with
|
|
save_fpu_regs() assuming they belong to user space and will be loaded into
|
|
fp/vx registers when returning to user space.
|
|
|
|
test_fp_ctl() restores the original user space fpc register value, however
|
|
it will be discarded, when returning to user space.
|
|
|
|
In result the tracer will incorrectly continue to run with the value that
|
|
was supposed to be used for the traced process.
|
|
|
|
Fix this by saving fpu register contents with save_fpu_regs() before using
|
|
test_fp_ctl().(CVE-2023-52598)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ext4: avoid online resizing failures due to oversized flex bg
|
|
|
|
When we online resize an ext4 filesystem with a oversized flexbg_size,
|
|
|
|
mkfs.ext4 -F -G 67108864 $dev -b 4096 100M
|
|
mount $dev $dir
|
|
resize2fs $dev 16G
|
|
|
|
the following WARN_ON is triggered:
|
|
==================================================================
|
|
WARNING: CPU: 0 PID: 427 at mm/page_alloc.c:4402 __alloc_pages+0x411/0x550
|
|
Modules linked in: sg(E)
|
|
CPU: 0 PID: 427 Comm: resize2fs Tainted: G E 6.6.0-rc5+ #314
|
|
RIP: 0010:__alloc_pages+0x411/0x550
|
|
Call Trace:
|
|
<TASK>
|
|
__kmalloc_large_node+0xa2/0x200
|
|
__kmalloc+0x16e/0x290
|
|
ext4_resize_fs+0x481/0xd80
|
|
__ext4_ioctl+0x1616/0x1d90
|
|
ext4_ioctl+0x12/0x20
|
|
__x64_sys_ioctl+0xf0/0x150
|
|
do_syscall_64+0x3b/0x90
|
|
==================================================================
|
|
|
|
This is because flexbg_size is too large and the size of the new_group_data
|
|
array to be allocated exceeds MAX_ORDER. Currently, the minimum value of
|
|
MAX_ORDER is 8, the minimum value of PAGE_SIZE is 4096, the corresponding
|
|
maximum number of groups that can be allocated is:
|
|
|
|
(PAGE_SIZE << MAX_ORDER) / sizeof(struct ext4_new_group_data) ≈ 21845
|
|
|
|
And the value that is down-aligned to the power of 2 is 16384. Therefore,
|
|
this value is defined as MAX_RESIZE_BG, and the number of groups added
|
|
each time does not exceed this value during resizing, and is added multiple
|
|
times to complete the online resizing. The difference is that the metadata
|
|
in a flex_bg may be more dispersed.(CVE-2023-52622)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ext4: regenerate buddy after block freeing failed if under fc replay
|
|
|
|
This mostly reverts commit 6bd97bf273bd ("ext4: remove redundant
|
|
mb_regenerate_buddy()") and reintroduces mb_regenerate_buddy(). Based on
|
|
code in mb_free_blocks(), fast commit replay can end up marking as free
|
|
blocks that are already marked as such. This causes corruption of the
|
|
buddy bitmap so we need to regenerate it in that case.(CVE-2024-26601)</Note>
|
|
<Note Title="Topic" Type="General" Ordinal="4" xml:lang="en">An update for kernel is now available for openEuler-22.03-LTS-SP3.
|
|
|
|
openEuler Security has rated this update as having a security impact of medium. A Common Vunlnerability Scoring System(CVSS)base score,which gives a detailed severity rating, is available for each vulnerability from the CVElink(s) in the References section.</Note>
|
|
<Note Title="Severity" Type="General" Ordinal="5" xml:lang="en">Medium</Note>
|
|
<Note Title="Affected Component" Type="General" Ordinal="6" xml:lang="en">kernel</Note>
|
|
</DocumentNotes>
|
|
<DocumentReferences>
|
|
<Reference Type="Self">
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1482</URL>
|
|
</Reference>
|
|
<Reference Type="openEuler CVE">
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-46926</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47070</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47101</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52464</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52475</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52500</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52507</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52510</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52515</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52522</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52525</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52530</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52560</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52561</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52566</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52568</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52573</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52577</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52578</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52583</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52587</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52594</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52595</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52597</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52598</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52622</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26601</URL>
|
|
</Reference>
|
|
<Reference Type="Other">
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-46926</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47070</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47101</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52464</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52475</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52500</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52507</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52510</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52515</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52522</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52525</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52530</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52560</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52561</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52566</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52568</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52573</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52577</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52578</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52583</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52587</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52594</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52595</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52597</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52598</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52622</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26601</URL>
|
|
</Reference>
|
|
</DocumentReferences>
|
|
<ProductTree xmlns="http://www.icasi.org/CVRF/schema/prod/1.1">
|
|
<Branch Type="Product Name" Name="openEuler">
|
|
<FullProductName ProductID="openEuler-22.03-LTS-SP3" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">openEuler-22.03-LTS-SP3</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="aarch64">
|
|
<FullProductName ProductID="kernel-5.10.0-196.0.0.109" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-5.10.0-196.0.0.109.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-5.10.0-196.0.0.109" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-devel-5.10.0-196.0.0.109.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-5.10.0-196.0.0.109" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-5.10.0-196.0.0.109.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-5.10.0-196.0.0.109" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-debuginfo-5.10.0-196.0.0.109.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-5.10.0-196.0.0.109" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-headers-5.10.0-196.0.0.109.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-5.10.0-196.0.0.109" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-5.10.0-196.0.0.109.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-5.10.0-196.0.0.109" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-5.10.0-196.0.0.109.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-5.10.0-196.0.0.109" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debugsource-5.10.0-196.0.0.109.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-5.10.0-196.0.0.109" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-devel-5.10.0-196.0.0.109.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-196.0.0.109" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-debuginfo-5.10.0-196.0.0.109.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-5.10.0-196.0.0.109" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debuginfo-5.10.0-196.0.0.109.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-196.0.0.109" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-debuginfo-5.10.0-196.0.0.109.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-5.10.0-196.0.0.109" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-source-5.10.0-196.0.0.109.oe2203sp3.aarch64.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="src">
|
|
<FullProductName ProductID="kernel-5.10.0-196.0.0.109" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-5.10.0-196.0.0.109.oe2203sp3.src.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="x86_64">
|
|
<FullProductName ProductID="kernel-5.10.0-196.0.0.109" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-5.10.0-196.0.0.109.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-5.10.0-196.0.0.109" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debugsource-5.10.0-196.0.0.109.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-5.10.0-196.0.0.109" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-devel-5.10.0-196.0.0.109.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-5.10.0-196.0.0.109" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-5.10.0-196.0.0.109.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-5.10.0-196.0.0.109" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-5.10.0-196.0.0.109.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-5.10.0-196.0.0.109" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debuginfo-5.10.0-196.0.0.109.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-5.10.0-196.0.0.109" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-source-5.10.0-196.0.0.109.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-5.10.0-196.0.0.109" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-5.10.0-196.0.0.109.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-5.10.0-196.0.0.109" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-devel-5.10.0-196.0.0.109.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-5.10.0-196.0.0.109" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-headers-5.10.0-196.0.0.109.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-5.10.0-196.0.0.109" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-debuginfo-5.10.0-196.0.0.109.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-196.0.0.109" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-debuginfo-5.10.0-196.0.0.109.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-196.0.0.109" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-debuginfo-5.10.0-196.0.0.109.oe2203sp3.x86_64.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:ALSA: hda: intel-sdw-acpi: harden detection of controllerThe existing code currently sets a pointer to an ACPI handle beforechecking that it s actually a SoundWire controller. This can lead toissues where the graph walk continues and eventually fails, but thepointer was set already.This patch changes the logic so that the information provided tothe caller is set when a controller is found.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-19</ReleaseDate>
|
|
<CVE>CVE-2021-46926</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-04-19</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1482</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="2" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
uio_hv_generic: Fix another memory leak in error handling paths
|
|
|
|
Memory allocated by 'vmbus_alloc_ring()' at the beginning of the probe
|
|
function is never freed in the error handling path.
|
|
|
|
Add the missing 'vmbus_free_ring()' call.
|
|
|
|
Note that it is already freed in the .remove function.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-19</ReleaseDate>
|
|
<CVE>CVE-2021-47070</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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:H/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-04-19</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1482</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="3" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
asix: fix uninit-value in asix_mdio_read()
|
|
|
|
asix_read_cmd() may read less than sizeof(smsr) bytes and in this case
|
|
smsr will be uninitialized.
|
|
|
|
Fail log:
|
|
BUG: KMSAN: uninit-value in asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline]
|
|
BUG: KMSAN: uninit-value in asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] drivers/net/usb/asix_common.c:497
|
|
BUG: KMSAN: uninit-value in asix_mdio_read+0x3c1/0xb00 drivers/net/usb/asix_common.c:497 drivers/net/usb/asix_common.c:497
|
|
asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline]
|
|
asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] drivers/net/usb/asix_common.c:497
|
|
asix_mdio_read+0x3c1/0xb00 drivers/net/usb/asix_common.c:497 drivers/net/usb/asix_common.c:497</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-19</ReleaseDate>
|
|
<CVE>CVE-2021-47101</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.0</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-04-19</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1482</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="4" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:EDAC/thunderx: Fix possible out-of-bounds string accessEnabling -Wstringop-overflow globally exposes a warning for a common bugin the usage of strncat(): drivers/edac/thunderx_edac.c: In function thunderx_ocx_com_threaded_isr : drivers/edac/thunderx_edac.c:1136:17: error: strncat specified bound 1024 equals destination size [-Werror=stringop-overflow=] 1136 | strncat(msg, other, OCX_MESSAGE_SIZE); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ... 1145 | strncat(msg, other, OCX_MESSAGE_SIZE); ... 1150 | strncat(msg, other, OCX_MESSAGE_SIZE); ...Apparently the author of this driver expected strncat() to behave theway that strlcat() does, which uses the size of the destination bufferas its third argument rather than the length of the source buffer. Theresult is that there is no check on the size of the allocated buffer.Change it to strlcat(). [ bp: Trim compiler output, fixup commit message. ]</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-19</ReleaseDate>
|
|
<CVE>CVE-2023-52464</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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:H/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-04-19</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1482</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="5" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
Input: powermate - fix use-after-free in powermate_config_complete
|
|
|
|
syzbot has found a use-after-free bug [1] in the powermate driver. This
|
|
happens when the device is disconnected, which leads to a memory free from
|
|
the powermate_device struct. When an asynchronous control message
|
|
completes after the kfree and its callback is invoked, the lock does not
|
|
exist anymore and hence the bug.
|
|
|
|
Use usb_kill_urb() on pm->config to cancel any in-progress requests upon
|
|
device disconnection.
|
|
|
|
[1] https://syzkaller.appspot.com/bug?extid=0434ac83f907a1dbdd1e</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-19</ReleaseDate>
|
|
<CVE>CVE-2023-52475</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>6.3</BaseScore>
|
|
<Vector>AV:P/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-04-19</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1482</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="6" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
scsi: pm80xx: Avoid leaking tags when processing OPC_INB_SET_CONTROLLER_CONFIG command
|
|
|
|
Tags allocated for OPC_INB_SET_CONTROLLER_CONFIG command need to be freed
|
|
when we receive the response.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-19</ReleaseDate>
|
|
<CVE>CVE-2023-52500</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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:L/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-04-19</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1482</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="7" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
nfc: nci: assert requested protocol is valid
|
|
|
|
The protocol is used in a bit mask to determine if the protocol is
|
|
supported. Assert the provided protocol is less than the maximum
|
|
defined so it doesn't potentially perform a shift-out-of-bounds and
|
|
provide a clearer error for undefined protocols vs unsupported ones.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-19</ReleaseDate>
|
|
<CVE>CVE-2023-52507</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.7</BaseScore>
|
|
<Vector>AV:A/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-04-19</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1482</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="8" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ieee802154: ca8210: Fix a potential UAF in ca8210_probe
|
|
|
|
If of_clk_add_provider() fails in ca8210_register_ext_clock(),
|
|
it calls clk_unregister() to release priv->clk and returns an
|
|
error. However, the caller ca8210_probe() then calls ca8210_remove(),
|
|
where priv->clk is freed again in ca8210_unregister_ext_clock(). In
|
|
this case, a use-after-free may happen in the second time we call
|
|
clk_unregister().
|
|
|
|
Fix this by removing the first clk_unregister(). Also, priv->clk could
|
|
be an error code on failure of clk_register_fixed_rate(). Use
|
|
IS_ERR_OR_NULL to catch this case in ca8210_unregister_ext_clock().</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-19</ReleaseDate>
|
|
<CVE>CVE-2023-52510</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-04-19</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1482</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="9" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
RDMA/srp: Do not call scsi_done() from srp_abort()
|
|
|
|
After scmd_eh_abort_handler() has called the SCSI LLD eh_abort_handler
|
|
callback, it performs one of the following actions:
|
|
* Call scsi_queue_insert().
|
|
* Call scsi_finish_command().
|
|
* Call scsi_eh_scmd_add().
|
|
Hence, SCSI abort handlers must not call scsi_done(). Otherwise all
|
|
the above actions would trigger a use-after-free. Hence remove the
|
|
scsi_done() call from srp_abort(). Keep the srp_free_req() call
|
|
before returning SUCCESS because we may not see the command again if
|
|
SUCCESS is returned.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-19</ReleaseDate>
|
|
<CVE>CVE-2023-52515</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-04-19</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1482</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="10" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: fix possible store tearing in neigh_periodic_work()
|
|
|
|
While looking at a related syzbot report involving neigh_periodic_work(),
|
|
I found that I forgot to add an annotation when deleting an
|
|
RCU protected item from a list.
|
|
|
|
Readers use rcu_deference(*np), we need to use either
|
|
rcu_assign_pointer() or WRITE_ONCE() on writer side
|
|
to prevent store tearing.
|
|
|
|
I use rcu_assign_pointer() to have lockdep support,
|
|
this was the choice made in neigh_flush_dev().</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-19</ReleaseDate>
|
|
<CVE>CVE-2023-52522</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-04-19</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1482</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="11" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: mwifiex: Fix oob check condition in mwifiex_process_rx_packet
|
|
|
|
Only skip the code path trying to access the rfc1042 headers when the
|
|
buffer is too small, so the driver can still process packets without
|
|
rfc1042 headers.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-19</ReleaseDate>
|
|
<CVE>CVE-2023-52525</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-04-19</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1482</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="12" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: mac80211: fix potential key use-after-free
|
|
|
|
When ieee80211_key_link() is called by ieee80211_gtk_rekey_add()
|
|
but returns 0 due to KRACK protection (identical key reinstall),
|
|
ieee80211_gtk_rekey_add() will still return a pointer into the
|
|
key, in a potential use-after-free. This normally doesn't happen
|
|
since it's only called by iwlwifi in case of WoWLAN rekey offload
|
|
which has its own KRACK protection, but still better to fix, do
|
|
that by returning an error code and converting that to success on
|
|
the cfg80211 boundary only, leaving the error for bad callers of
|
|
ieee80211_gtk_rekey_add().</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-19</ReleaseDate>
|
|
<CVE>CVE-2023-52530</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-04-19</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1482</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="13" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
mm/damon/vaddr-test: fix memory leak in damon_do_test_apply_three_regions()
|
|
|
|
When CONFIG_DAMON_VADDR_KUNIT_TEST=y and making CONFIG_DEBUG_KMEMLEAK=y
|
|
and CONFIG_DEBUG_KMEMLEAK_AUTO_SCAN=y, the below memory leak is detected.
|
|
|
|
Since commit 9f86d624292c ("mm/damon/vaddr-test: remove unnecessary
|
|
variables"), the damon_destroy_ctx() is removed, but still call
|
|
damon_new_target() and damon_new_region(), the damon_region which is
|
|
allocated by kmem_cache_alloc() in damon_new_region() and the damon_target
|
|
which is allocated by kmalloc in damon_new_target() are not freed. And
|
|
the damon_region which is allocated in damon_new_region() in
|
|
damon_set_regions() is also not freed.
|
|
|
|
So use damon_destroy_target to free all the damon_regions and damon_target.
|
|
|
|
unreferenced object 0xffff888107c9a940 (size 64):
|
|
comm "kunit_try_catch", pid 1069, jiffies 4294670592 (age 732.761s)
|
|
hex dump (first 32 bytes):
|
|
00 00 00 00 00 00 00 00 06 00 00 00 6b 6b 6b 6b ............kkkk
|
|
60 c7 9c 07 81 88 ff ff f8 cb 9c 07 81 88 ff ff `...............
|
|
backtrace:
|
|
[<ffffffff817e0167>] kmalloc_trace+0x27/0xa0
|
|
[<ffffffff819c11cf>] damon_new_target+0x3f/0x1b0
|
|
[<ffffffff819c7d55>] damon_do_test_apply_three_regions.constprop.0+0x95/0x3e0
|
|
[<ffffffff819c82be>] damon_test_apply_three_regions1+0x21e/0x260
|
|
[<ffffffff829fce6a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
|
|
[<ffffffff81237cf6>] kthread+0x2b6/0x380
|
|
[<ffffffff81097add>] ret_from_fork+0x2d/0x70
|
|
[<ffffffff81003791>] ret_from_fork_asm+0x11/0x20
|
|
unreferenced object 0xffff8881079cc740 (size 56):
|
|
comm "kunit_try_catch", pid 1069, jiffies 4294670592 (age 732.761s)
|
|
hex dump (first 32 bytes):
|
|
05 00 00 00 00 00 00 00 14 00 00 00 00 00 00 00 ................
|
|
6b 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 6b 6b 6b 6b kkkkkkkk....kkkk
|
|
backtrace:
|
|
[<ffffffff819bc492>] damon_new_region+0x22/0x1c0
|
|
[<ffffffff819c7d91>] damon_do_test_apply_three_regions.constprop.0+0xd1/0x3e0
|
|
[<ffffffff819c82be>] damon_test_apply_three_regions1+0x21e/0x260
|
|
[<ffffffff829fce6a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
|
|
[<ffffffff81237cf6>] kthread+0x2b6/0x380
|
|
[<ffffffff81097add>] ret_from_fork+0x2d/0x70
|
|
[<ffffffff81003791>] ret_from_fork_asm+0x11/0x20
|
|
unreferenced object 0xffff888107c9ac40 (size 64):
|
|
comm "kunit_try_catch", pid 1071, jiffies 4294670595 (age 732.843s)
|
|
hex dump (first 32 bytes):
|
|
00 00 00 00 00 00 00 00 06 00 00 00 6b 6b 6b 6b ............kkkk
|
|
a0 cc 9c 07 81 88 ff ff 78 a1 76 07 81 88 ff ff ........x.v.....
|
|
backtrace:
|
|
[<ffffffff817e0167>] kmalloc_trace+0x27/0xa0
|
|
[<ffffffff819c11cf>] damon_new_target+0x3f/0x1b0
|
|
[<ffffffff819c7d55>] damon_do_test_apply_three_regions.constprop.0+0x95/0x3e0
|
|
[<ffffffff819c851e>] damon_test_apply_three_regions2+0x21e/0x260
|
|
[<ffffffff829fce6a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
|
|
[<ffffffff81237cf6>] kthread+0x2b6/0x380
|
|
[<ffffffff81097add>] ret_from_fork+0x2d/0x70
|
|
[<ffffffff81003791>] ret_from_fork_asm+0x11/0x20
|
|
unreferenced object 0xffff8881079ccc80 (size 56):
|
|
comm "kunit_try_catch", pid 1071, jiffies 4294670595 (age 732.843s)
|
|
hex dump (first 32 bytes):
|
|
05 00 00 00 00 00 00 00 14 00 00 00 00 00 00 00 ................
|
|
6b 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 6b 6b 6b 6b kkkkkkkk....kkkk
|
|
backtrace:
|
|
[<ffffffff819bc492>] damon_new_region+0x22/0x1c0
|
|
[<ffffffff819c7d91>] damon_do_test_apply_three_regions.constprop.0+0xd1/0x3e0
|
|
[<ffffffff819c851e>] damon_test_apply_three_regions2+0x21e/0x260
|
|
[<ffffffff829fce6a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
|
|
[<ffffffff81237cf6>] kthread+0x2b6/0x380
|
|
[<ffffffff81097add>] ret_from_fork+0x2d/0x70
|
|
[<ffff
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-19</ReleaseDate>
|
|
<CVE>CVE-2023-52560</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-04-19</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1482</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="14" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="14" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
arm64: dts: qcom: sdm845-db845c: Mark cont splash memory region as reserved
|
|
|
|
Adding a reserved memory region for the framebuffer memory
|
|
(the splash memory region set up by the bootloader).
|
|
|
|
It fixes a kernel panic (arm-smmu: Unhandled context fault
|
|
at this particular memory region) reported on DB845c running
|
|
v5.10.y.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-19</ReleaseDate>
|
|
<CVE>CVE-2023-52561</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-04-19</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1482</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="15" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="15" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
nilfs2: fix potential use after free in nilfs_gccache_submit_read_data()
|
|
|
|
In nilfs_gccache_submit_read_data(), brelse(bh) is called to drop the
|
|
reference count of bh when the call to nilfs_dat_translate() fails. If
|
|
the reference count hits 0 and its owner page gets unlocked, bh may be
|
|
freed. However, bh->b_page is dereferenced to put the page after that,
|
|
which may result in a use-after-free bug. This patch moves the release
|
|
operation after unlocking and putting the page.
|
|
|
|
NOTE: The function in question is only called in GC, and in combination
|
|
with current userland tools, address translation using DAT does not occur
|
|
in that function, so the code path that causes this issue will not be
|
|
executed. However, it is possible to run that code path by intentionally
|
|
modifying the userland GC library or by calling the GC ioctl directly.
|
|
|
|
[konishi.ryusuke@gmail.com: NOTE added to the commit log]</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-19</ReleaseDate>
|
|
<CVE>CVE-2023-52566</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-04-19</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1482</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="16" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="16" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
x86/sgx: Resolves SECS reclaim vs. page fault for EAUG race
|
|
|
|
The SGX EPC reclaimer (ksgxd) may reclaim the SECS EPC page for an
|
|
enclave and set secs.epc_page to NULL. The SECS page is used for EAUG
|
|
and ELDU in the SGX page fault handler. However, the NULL check for
|
|
secs.epc_page is only done for ELDU, not EAUG before being used.
|
|
|
|
Fix this by doing the same NULL check and reloading of the SECS page as
|
|
needed for both EAUG and ELDU.
|
|
|
|
The SECS page holds global enclave metadata. It can only be reclaimed
|
|
when there are no other enclave pages remaining. At that point,
|
|
virtually nothing can be done with the enclave until the SECS page is
|
|
paged back in.
|
|
|
|
An enclave can not run nor generate page faults without a resident SECS
|
|
page. But it is still possible for a #PF for a non-SECS page to race
|
|
with paging out the SECS page: when the last resident non-SECS page A
|
|
triggers a #PF in a non-resident page B, and then page A and the SECS
|
|
both are paged out before the #PF on B is handled.
|
|
|
|
Hitting this bug requires that race triggered with a #PF for EAUG.
|
|
Following is a trace when it happens.
|
|
|
|
BUG: kernel NULL pointer dereference, address: 0000000000000000
|
|
RIP: 0010:sgx_encl_eaug_page+0xc7/0x210
|
|
Call Trace:
|
|
? __kmem_cache_alloc_node+0x16a/0x440
|
|
? xa_load+0x6e/0xa0
|
|
sgx_vma_fault+0x119/0x230
|
|
__do_fault+0x36/0x140
|
|
do_fault+0x12f/0x400
|
|
__handle_mm_fault+0x728/0x1110
|
|
handle_mm_fault+0x105/0x310
|
|
do_user_addr_fault+0x1ee/0x750
|
|
? __this_cpu_preempt_check+0x13/0x20
|
|
exc_page_fault+0x76/0x180
|
|
asm_exc_page_fault+0x27/0x30</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-19</ReleaseDate>
|
|
<CVE>CVE-2023-52568</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-04-19</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1482</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="17" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="17" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: rds: Fix possible NULL-pointer dereference
|
|
|
|
In rds_rdma_cm_event_handler_cmn() check, if conn pointer exists
|
|
before dereferencing it as rdma_set_service_type() argument
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with SVACE.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-19</ReleaseDate>
|
|
<CVE>CVE-2023-52573</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-04-19</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1482</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="18" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="18" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
dccp: fix dccp_v4_err()/dccp_v6_err() again
|
|
|
|
dh->dccph_x is the 9th byte (offset 8) in "struct dccp_hdr",
|
|
not in the "byte 7" as Jann claimed.
|
|
|
|
We need to make sure the ICMP messages are big enough,
|
|
using more standard ways (no more assumptions).
|
|
|
|
syzbot reported:
|
|
BUG: KMSAN: uninit-value in pskb_may_pull_reason include/linux/skbuff.h:2667 [inline]
|
|
BUG: KMSAN: uninit-value in pskb_may_pull include/linux/skbuff.h:2681 [inline]
|
|
BUG: KMSAN: uninit-value in dccp_v6_err+0x426/0x1aa0 net/dccp/ipv6.c:94
|
|
pskb_may_pull_reason include/linux/skbuff.h:2667 [inline]
|
|
pskb_may_pull include/linux/skbuff.h:2681 [inline]
|
|
dccp_v6_err+0x426/0x1aa0 net/dccp/ipv6.c:94
|
|
icmpv6_notify+0x4c7/0x880 net/ipv6/icmp.c:867
|
|
icmpv6_rcv+0x19d5/0x30d0
|
|
ip6_protocol_deliver_rcu+0xda6/0x2a60 net/ipv6/ip6_input.c:438
|
|
ip6_input_finish net/ipv6/ip6_input.c:483 [inline]
|
|
NF_HOOK include/linux/netfilter.h:304 [inline]
|
|
ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492
|
|
ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586
|
|
dst_input include/net/dst.h:468 [inline]
|
|
ip6_rcv_finish+0x5db/0x870 net/ipv6/ip6_input.c:79
|
|
NF_HOOK include/linux/netfilter.h:304 [inline]
|
|
ipv6_rcv+0xda/0x390 net/ipv6/ip6_input.c:310
|
|
__netif_receive_skb_one_core net/core/dev.c:5523 [inline]
|
|
__netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5637
|
|
netif_receive_skb_internal net/core/dev.c:5723 [inline]
|
|
netif_receive_skb+0x58/0x660 net/core/dev.c:5782
|
|
tun_rx_batched+0x83b/0x920
|
|
tun_get_user+0x564c/0x6940 drivers/net/tun.c:2002
|
|
tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048
|
|
call_write_iter include/linux/fs.h:1985 [inline]
|
|
new_sync_write fs/read_write.c:491 [inline]
|
|
vfs_write+0x8ef/0x15c0 fs/read_write.c:584
|
|
ksys_write+0x20f/0x4c0 fs/read_write.c:637
|
|
__do_sys_write fs/read_write.c:649 [inline]
|
|
__se_sys_write fs/read_write.c:646 [inline]
|
|
__x64_sys_write+0x93/0xd0 fs/read_write.c:646
|
|
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
|
|
do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
|
|
entry_SYSCALL_64_after_hwframe+0x63/0xcd
|
|
|
|
Uninit was created at:
|
|
slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767
|
|
slab_alloc_node mm/slub.c:3478 [inline]
|
|
kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523
|
|
kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:559
|
|
__alloc_skb+0x318/0x740 net/core/skbuff.c:650
|
|
alloc_skb include/linux/skbuff.h:1286 [inline]
|
|
alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6313
|
|
sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2795
|
|
tun_alloc_skb drivers/net/tun.c:1531 [inline]
|
|
tun_get_user+0x23cf/0x6940 drivers/net/tun.c:1846
|
|
tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048
|
|
call_write_iter include/linux/fs.h:1985 [inline]
|
|
new_sync_write fs/read_write.c:491 [inline]
|
|
vfs_write+0x8ef/0x15c0 fs/read_write.c:584
|
|
ksys_write+0x20f/0x4c0 fs/read_write.c:637
|
|
__do_sys_write fs/read_write.c:649 [inline]
|
|
__se_sys_write fs/read_write.c:646 [inline]
|
|
__x64_sys_write+0x93/0xd0 fs/read_write.c:646
|
|
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
|
|
do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
|
|
entry_SYSCALL_64_after_hwframe+0x63/0xcd
|
|
|
|
CPU: 0 PID: 4995 Comm: syz-executor153 Not tainted 6.6.0-rc1-syzkaller-00014-ga747acc0b752 #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-19</ReleaseDate>
|
|
<CVE>CVE-2023-52577</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-04-19</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1482</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="19" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="19" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: bridge: use DEV_STATS_INC()
|
|
|
|
syzbot/KCSAN reported data-races in br_handle_frame_finish() [1]
|
|
This function can run from multiple cpus without mutual exclusion.
|
|
|
|
Adopt SMP safe DEV_STATS_INC() to update dev->stats fields.
|
|
|
|
Handles updates to dev->stats.tx_dropped while we are at it.
|
|
|
|
[1]
|
|
BUG: KCSAN: data-race in br_handle_frame_finish / br_handle_frame_finish
|
|
|
|
read-write to 0xffff8881374b2178 of 8 bytes by interrupt on cpu 1:
|
|
br_handle_frame_finish+0xd4f/0xef0 net/bridge/br_input.c:189
|
|
br_nf_hook_thresh+0x1ed/0x220
|
|
br_nf_pre_routing_finish_ipv6+0x50f/0x540
|
|
NF_HOOK include/linux/netfilter.h:304 [inline]
|
|
br_nf_pre_routing_ipv6+0x1e3/0x2a0 net/bridge/br_netfilter_ipv6.c:178
|
|
br_nf_pre_routing+0x526/0xba0 net/bridge/br_netfilter_hooks.c:508
|
|
nf_hook_entry_hookfn include/linux/netfilter.h:144 [inline]
|
|
nf_hook_bridge_pre net/bridge/br_input.c:272 [inline]
|
|
br_handle_frame+0x4c9/0x940 net/bridge/br_input.c:417
|
|
__netif_receive_skb_core+0xa8a/0x21e0 net/core/dev.c:5417
|
|
__netif_receive_skb_one_core net/core/dev.c:5521 [inline]
|
|
__netif_receive_skb+0x57/0x1b0 net/core/dev.c:5637
|
|
process_backlog+0x21f/0x380 net/core/dev.c:5965
|
|
__napi_poll+0x60/0x3b0 net/core/dev.c:6527
|
|
napi_poll net/core/dev.c:6594 [inline]
|
|
net_rx_action+0x32b/0x750 net/core/dev.c:6727
|
|
__do_softirq+0xc1/0x265 kernel/softirq.c:553
|
|
run_ksoftirqd+0x17/0x20 kernel/softirq.c:921
|
|
smpboot_thread_fn+0x30a/0x4a0 kernel/smpboot.c:164
|
|
kthread+0x1d7/0x210 kernel/kthread.c:388
|
|
ret_from_fork+0x48/0x60 arch/x86/kernel/process.c:147
|
|
ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
|
|
|
|
read-write to 0xffff8881374b2178 of 8 bytes by interrupt on cpu 0:
|
|
br_handle_frame_finish+0xd4f/0xef0 net/bridge/br_input.c:189
|
|
br_nf_hook_thresh+0x1ed/0x220
|
|
br_nf_pre_routing_finish_ipv6+0x50f/0x540
|
|
NF_HOOK include/linux/netfilter.h:304 [inline]
|
|
br_nf_pre_routing_ipv6+0x1e3/0x2a0 net/bridge/br_netfilter_ipv6.c:178
|
|
br_nf_pre_routing+0x526/0xba0 net/bridge/br_netfilter_hooks.c:508
|
|
nf_hook_entry_hookfn include/linux/netfilter.h:144 [inline]
|
|
nf_hook_bridge_pre net/bridge/br_input.c:272 [inline]
|
|
br_handle_frame+0x4c9/0x940 net/bridge/br_input.c:417
|
|
__netif_receive_skb_core+0xa8a/0x21e0 net/core/dev.c:5417
|
|
__netif_receive_skb_one_core net/core/dev.c:5521 [inline]
|
|
__netif_receive_skb+0x57/0x1b0 net/core/dev.c:5637
|
|
process_backlog+0x21f/0x380 net/core/dev.c:5965
|
|
__napi_poll+0x60/0x3b0 net/core/dev.c:6527
|
|
napi_poll net/core/dev.c:6594 [inline]
|
|
net_rx_action+0x32b/0x750 net/core/dev.c:6727
|
|
__do_softirq+0xc1/0x265 kernel/softirq.c:553
|
|
do_softirq+0x5e/0x90 kernel/softirq.c:454
|
|
__local_bh_enable_ip+0x64/0x70 kernel/softirq.c:381
|
|
__raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline]
|
|
_raw_spin_unlock_bh+0x36/0x40 kernel/locking/spinlock.c:210
|
|
spin_unlock_bh include/linux/spinlock.h:396 [inline]
|
|
batadv_tt_local_purge+0x1a8/0x1f0 net/batman-adv/translation-table.c:1356
|
|
batadv_tt_purge+0x2b/0x630 net/batman-adv/translation-table.c:3560
|
|
process_one_work kernel/workqueue.c:2630 [inline]
|
|
process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2703
|
|
worker_thread+0x525/0x730 kernel/workqueue.c:2784
|
|
kthread+0x1d7/0x210 kernel/kthread.c:388
|
|
ret_from_fork+0x48/0x60 arch/x86/kernel/process.c:147
|
|
ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
|
|
|
|
value changed: 0x00000000000d7190 -> 0x00000000000d7191
|
|
|
|
Reported by Kernel Concurrency Sanitizer on:
|
|
CPU: 0 PID: 14848 Comm: kworker/u4:11 Not tainted 6.6.0-rc1-syzkaller-00236-gad8a69f361b9 #0</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-19</ReleaseDate>
|
|
<CVE>CVE-2023-52578</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-04-19</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1482</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="20" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="20" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ceph: fix deadlock or deadcode of misusing dget()
|
|
|
|
The lock order is incorrect between denty and its parent, we should
|
|
always make sure that the parent get the lock first.
|
|
|
|
But since this deadcode is never used and the parent dir will always
|
|
be set from the callers, let's just remove it.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-19</ReleaseDate>
|
|
<CVE>CVE-2023-52583</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-04-19</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1482</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="21" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="21" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
IB/ipoib: Fix mcast list locking
|
|
|
|
Releasing the `priv->lock` while iterating the `priv->multicast_list` in
|
|
`ipoib_mcast_join_task()` opens a window for `ipoib_mcast_dev_flush()` to
|
|
remove the items while in the middle of iteration. If the mcast is removed
|
|
while the lock was dropped, the for loop spins forever resulting in a hard
|
|
lockup (as was reported on RHEL 4.18.0-372.75.1.el8_6 kernel):
|
|
|
|
Task A (kworker/u72:2 below) | Task B (kworker/u72:0 below)
|
|
-----------------------------------+-----------------------------------
|
|
ipoib_mcast_join_task(work) | ipoib_ib_dev_flush_light(work)
|
|
spin_lock_irq(&priv->lock) | __ipoib_ib_dev_flush(priv, ...)
|
|
list_for_each_entry(mcast, | ipoib_mcast_dev_flush(dev = priv->dev)
|
|
&priv->multicast_list, list) |
|
|
ipoib_mcast_join(dev, mcast) |
|
|
spin_unlock_irq(&priv->lock) |
|
|
| spin_lock_irqsave(&priv->lock, flags)
|
|
| list_for_each_entry_safe(mcast, tmcast,
|
|
| &priv->multicast_list, list)
|
|
| list_del(&mcast->list);
|
|
| list_add_tail(&mcast->list, &remove_list)
|
|
| spin_unlock_irqrestore(&priv->lock, flags)
|
|
spin_lock_irq(&priv->lock) |
|
|
| ipoib_mcast_remove_list(&remove_list)
|
|
(Here, `mcast` is no longer on the | list_for_each_entry_safe(mcast, tmcast,
|
|
`priv->multicast_list` and we keep | remove_list, list)
|
|
spinning on the `remove_list` of | >>> wait_for_completion(&mcast->done)
|
|
the other thread which is blocked |
|
|
and the list is still valid on |
|
|
it's stack.)
|
|
|
|
Fix this by keeping the lock held and changing to GFP_ATOMIC to prevent
|
|
eventual sleeps.
|
|
Unfortunately we could not reproduce the lockup and confirm this fix but
|
|
based on the code review I think this fix should address such lockups.
|
|
|
|
crash> bc 31
|
|
PID: 747 TASK: ff1c6a1a007e8000 CPU: 31 COMMAND: "kworker/u72:2"
|
|
--
|
|
[exception RIP: ipoib_mcast_join_task+0x1b1]
|
|
RIP: ffffffffc0944ac1 RSP: ff646f199a8c7e00 RFLAGS: 00000002
|
|
RAX: 0000000000000000 RBX: ff1c6a1a04dc82f8 RCX: 0000000000000000
|
|
work (&priv->mcast_task{,.work})
|
|
RDX: ff1c6a192d60ac68 RSI: 0000000000000286 RDI: ff1c6a1a04dc8000
|
|
&mcast->list
|
|
RBP: ff646f199a8c7e90 R8: ff1c699980019420 R9: ff1c6a1920c9a000
|
|
R10: ff646f199a8c7e00 R11: ff1c6a191a7d9800 R12: ff1c6a192d60ac00
|
|
mcast
|
|
R13: ff1c6a1d82200000 R14: ff1c6a1a04dc8000 R15: ff1c6a1a04dc82d8
|
|
dev priv (&priv->lock) &priv->multicast_list (aka head)
|
|
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
|
|
--- <NMI exception stack> ---
|
|
#5 [ff646f199a8c7e00] ipoib_mcast_join_task+0x1b1 at ffffffffc0944ac1 [ib_ipoib]
|
|
#6 [ff646f199a8c7e98] process_one_work+0x1a7 at ffffffff9bf10967
|
|
|
|
crash> rx ff646f199a8c7e68
|
|
ff646f199a8c7e68: ff1c6a1a04dc82f8 <<< work = &priv->mcast_task.work
|
|
|
|
crash> list -hO ipoib_dev_priv.multicast_list ff1c6a1a04dc8000
|
|
(empty)
|
|
|
|
crash> ipoib_dev_priv.mcast_task.work.func,mcast_mutex.owner.counter ff1c6a1a04dc8000
|
|
mcast_task.work.func = 0xffffffffc0944910 <ipoib_mcast_join_task>,
|
|
mcast_mutex.owner.counter = 0xff1c69998efec000
|
|
|
|
crash> b 8
|
|
PID: 8 TASK: ff1c69998efec000 CPU: 33 COMMAND: "kworker/u72:0"
|
|
--
|
|
#3 [ff646f1980153d50] wait_for_completion+0x96 at ffffffff9c7d7646
|
|
#4 [ff646f1980153d90] ipoib_mcast_remove_list+0x56 at ffffffffc0944dc6 [ib_ipoib]
|
|
#5 [ff646f1980153de8] ipoib_mcast_dev_flush+0x1a7 at ffffffffc09455a7 [ib_ipoib]
|
|
#6 [ff646f1980153e58] __ipoib_ib_dev_flush+0x1a4 at ffffffffc09431a4 [ib_ipoib]
|
|
#7 [ff
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-19</ReleaseDate>
|
|
<CVE>CVE-2023-52587</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.7</BaseScore>
|
|
<Vector>AV:L/AC:H/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-04-19</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1482</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="22" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="22" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: ath9k: Fix potential array-index-out-of-bounds read in ath9k_htc_txstatus()
|
|
|
|
Fix an array-index-out-of-bounds read in ath9k_htc_txstatus(). The bug
|
|
occurs when txs->cnt, data from a URB provided by a USB device, is
|
|
bigger than the size of the array txs->txstatus, which is
|
|
HTC_MAX_TX_STATUS. WARN_ON() already checks it, but there is no bug
|
|
handling code after the check. Make the function return if that is the
|
|
case.
|
|
|
|
Found by a modified version of syzkaller.
|
|
|
|
UBSAN: array-index-out-of-bounds in htc_drv_txrx.c
|
|
index 13 is out of range for type '__wmi_event_txstatus [12]'
|
|
Call Trace:
|
|
ath9k_htc_txstatus
|
|
ath9k_wmi_event_tasklet
|
|
tasklet_action_common
|
|
__do_softirq
|
|
irq_exit_rxu
|
|
sysvec_apic_timer_interrupt</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-19</ReleaseDate>
|
|
<CVE>CVE-2023-52594</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-04-19</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1482</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="23" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="23" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: rt2x00: restart beacon queue when hardware reset
|
|
|
|
When a hardware reset is triggered, all registers are reset, so all
|
|
queues are forced to stop in hardware interface. However, mac80211
|
|
will not automatically stop the queue. If we don't manually stop the
|
|
beacon queue, the queue will be deadlocked and unable to start again.
|
|
This patch fixes the issue where Apple devices cannot connect to the
|
|
AP after calling ieee80211_restart_hw().</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-19</ReleaseDate>
|
|
<CVE>CVE-2023-52595</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-04-19</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1482</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="24" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="24" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
KVM: s390: fix setting of fpc register
|
|
|
|
kvm_arch_vcpu_ioctl_set_fpu() allows to set the floating point control
|
|
(fpc) register of a guest cpu. The new value is tested for validity by
|
|
temporarily loading it into the fpc register.
|
|
|
|
This may lead to corruption of the fpc register of the host process:
|
|
if an interrupt happens while the value is temporarily loaded into the fpc
|
|
register, and within interrupt context floating point or vector registers
|
|
are used, the current fp/vx registers are saved with save_fpu_regs()
|
|
assuming they belong to user space and will be loaded into fp/vx registers
|
|
when returning to user space.
|
|
|
|
test_fp_ctl() restores the original user space / host process fpc register
|
|
value, however it will be discarded, when returning to user space.
|
|
|
|
In result the host process will incorrectly continue to run with the value
|
|
that was supposed to be used for a guest cpu.
|
|
|
|
Fix this by simply removing the test. There is another test right before
|
|
the SIE context is entered which will handles invalid values.
|
|
|
|
This results in a change of behaviour: invalid values will now be accepted
|
|
instead of that the ioctl fails with -EINVAL. This seems to be acceptable,
|
|
given that this interface is most likely not used anymore, and this is in
|
|
addition the same behaviour implemented with the memory mapped interface
|
|
(replace invalid values with zero) - see sync_regs() in kvm-s390.c.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-19</ReleaseDate>
|
|
<CVE>CVE-2023-52597</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.7</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:H/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-04-19</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1482</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="25" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="25" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
s390/ptrace: handle setting of fpc register correctly
|
|
|
|
If the content of the floating point control (fpc) register of a traced
|
|
process is modified with the ptrace interface the new value is tested for
|
|
validity by temporarily loading it into the fpc register.
|
|
|
|
This may lead to corruption of the fpc register of the tracing process:
|
|
if an interrupt happens while the value is temporarily loaded into the
|
|
fpc register, and within interrupt context floating point or vector
|
|
registers are used, the current fp/vx registers are saved with
|
|
save_fpu_regs() assuming they belong to user space and will be loaded into
|
|
fp/vx registers when returning to user space.
|
|
|
|
test_fp_ctl() restores the original user space fpc register value, however
|
|
it will be discarded, when returning to user space.
|
|
|
|
In result the tracer will incorrectly continue to run with the value that
|
|
was supposed to be used for the traced process.
|
|
|
|
Fix this by saving fpu register contents with save_fpu_regs() before using
|
|
test_fp_ctl().</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-19</ReleaseDate>
|
|
<CVE>CVE-2023-52598</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-04-19</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1482</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="26" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="26" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ext4: avoid online resizing failures due to oversized flex bg
|
|
|
|
When we online resize an ext4 filesystem with a oversized flexbg_size,
|
|
|
|
mkfs.ext4 -F -G 67108864 $dev -b 4096 100M
|
|
mount $dev $dir
|
|
resize2fs $dev 16G
|
|
|
|
the following WARN_ON is triggered:
|
|
==================================================================
|
|
WARNING: CPU: 0 PID: 427 at mm/page_alloc.c:4402 __alloc_pages+0x411/0x550
|
|
Modules linked in: sg(E)
|
|
CPU: 0 PID: 427 Comm: resize2fs Tainted: G E 6.6.0-rc5+ #314
|
|
RIP: 0010:__alloc_pages+0x411/0x550
|
|
Call Trace:
|
|
<TASK>
|
|
__kmalloc_large_node+0xa2/0x200
|
|
__kmalloc+0x16e/0x290
|
|
ext4_resize_fs+0x481/0xd80
|
|
__ext4_ioctl+0x1616/0x1d90
|
|
ext4_ioctl+0x12/0x20
|
|
__x64_sys_ioctl+0xf0/0x150
|
|
do_syscall_64+0x3b/0x90
|
|
==================================================================
|
|
|
|
This is because flexbg_size is too large and the size of the new_group_data
|
|
array to be allocated exceeds MAX_ORDER. Currently, the minimum value of
|
|
MAX_ORDER is 8, the minimum value of PAGE_SIZE is 4096, the corresponding
|
|
maximum number of groups that can be allocated is:
|
|
|
|
(PAGE_SIZE << MAX_ORDER) / sizeof(struct ext4_new_group_data) ≈ 21845
|
|
|
|
And the value that is down-aligned to the power of 2 is 16384. Therefore,
|
|
this value is defined as MAX_RESIZE_BG, and the number of groups added
|
|
each time does not exceed this value during resizing, and is added multiple
|
|
times to complete the online resizing. The difference is that the metadata
|
|
in a flex_bg may be more dispersed.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-19</ReleaseDate>
|
|
<CVE>CVE-2023-52622</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-04-19</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1482</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="27" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="27" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:ext4: regenerate buddy after block freeing failed if under fc replayThis mostly reverts commit 6bd97bf273bd ( ext4: remove redundantmb_regenerate_buddy() ) and reintroduces mb_regenerate_buddy(). Based oncode in mb_free_blocks(), fast commit replay can end up marking as freeblocks that are already marked as such. This causes corruption of thebuddy bitmap so we need to regenerate it in that case.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-04-19</ReleaseDate>
|
|
<CVE>CVE-2024-26601</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-04-19</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1482</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
</cvrfdoc> |