2710 lines
115 KiB
XML
2710 lines
115 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-20.03-LTS-SP4</DocumentTitle>
|
|
<DocumentType>Security Advisory</DocumentType>
|
|
<DocumentPublisher Type="Vendor">
|
|
<ContactDetails>openeuler-security@openeuler.org</ContactDetails>
|
|
<IssuingAuthority>openEuler security committee</IssuingAuthority>
|
|
</DocumentPublisher>
|
|
<DocumentTracking>
|
|
<Identification>
|
|
<ID>openEuler-SA-2024-1767</ID>
|
|
</Identification>
|
|
<Status>Final</Status>
|
|
<Version>1.0</Version>
|
|
<RevisionHistory>
|
|
<Revision>
|
|
<Number>1.0</Number>
|
|
<Date>2024-06-28</Date>
|
|
<Description>Initial</Description>
|
|
</Revision>
|
|
</RevisionHistory>
|
|
<InitialReleaseDate>2024-06-28</InitialReleaseDate>
|
|
<CurrentReleaseDate>2024-06-28</CurrentReleaseDate>
|
|
<Generator>
|
|
<Engine>openEuler SA Tool V1.0</Engine>
|
|
<Date>2024-06-28</Date>
|
|
</Generator>
|
|
</DocumentTracking>
|
|
<DocumentNotes>
|
|
<Note Title="Synopsis" Type="General" Ordinal="1" xml:lang="en">kernel security update</Note>
|
|
<Note Title="Summary" Type="General" Ordinal="2" xml:lang="en">An update for kernel is now available for openEuler-20.03-LTS-SP4.</Note>
|
|
<Note Title="Description" Type="General" Ordinal="3" xml:lang="en">The Linux Kernel, the operating system core itself.
|
|
|
|
Security Fix(es):
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
can: mcba_usb: fix memory leak in mcba_usb
|
|
|
|
Syzbot reported memory leak in SocketCAN driver for Microchip CAN BUS
|
|
Analyzer Tool. The problem was in unfreed usb_coherent.
|
|
|
|
In mcba_usb_start() 20 coherent buffers are allocated and there is
|
|
nothing, that frees them:
|
|
|
|
1) In callback function the urb is resubmitted and that's all
|
|
2) In disconnect function urbs are simply killed, but URB_FREE_BUFFER
|
|
is not set (see mcba_usb_start) and this flag cannot be used with
|
|
coherent buffers.
|
|
|
|
Fail log:
|
|
| [ 1354.053291][ T8413] mcba_usb 1-1:0.0 can0: device disconnected
|
|
| [ 1367.059384][ T8420] kmemleak: 20 new suspected memory leaks (see /sys/kernel/debug/kmem)
|
|
|
|
So, all allocated buffers should be freed with usb_free_coherent()
|
|
explicitly
|
|
|
|
NOTE:
|
|
The same pattern for allocating and freeing coherent buffers
|
|
is used in drivers/net/can/usb/kvaser_usb/kvaser_usb_core.c(CVE-2021-47231)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
can: j1939: fix Use-after-Free, hold skb ref while in use
|
|
|
|
This patch fixes a Use-after-Free found by the syzbot.
|
|
|
|
The problem is that a skb is taken from the per-session skb queue,
|
|
without incrementing the ref count. This leads to a Use-after-Free if
|
|
the skb is taken concurrently from the session queue due to a CTS.(CVE-2021-47232)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
batman-adv: Avoid WARN_ON timing related checks
|
|
|
|
The soft/batadv interface for a queued OGM can be changed during the time
|
|
the OGM was queued for transmission and when the OGM is actually
|
|
transmitted by the worker.
|
|
|
|
But WARN_ON must be used to denote kernel bugs and not to print simple
|
|
warnings. A warning can simply be printed using pr_warn.(CVE-2021-47252)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
media: ngene: Fix out-of-bounds bug in ngene_command_config_free_buf()
|
|
|
|
Fix an 11-year old bug in ngene_command_config_free_buf() while
|
|
addressing the following warnings caught with -Warray-bounds:
|
|
|
|
arch/alpha/include/asm/string.h:22:16: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds]
|
|
arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds]
|
|
|
|
The problem is that the original code is trying to copy 6 bytes of
|
|
data into a one-byte size member _config_ of the wrong structue
|
|
FW_CONFIGURE_BUFFERS, in a single call to memcpy(). This causes a
|
|
legitimate compiler warning because memcpy() overruns the length
|
|
of &com.cmd.ConfigureBuffers.config. It seems that the right
|
|
structure is FW_CONFIGURE_FREE_BUFFERS, instead, because it contains
|
|
6 more members apart from the header _hdr_. Also, the name of
|
|
the function ngene_command_config_free_buf() suggests that the actual
|
|
intention is to ConfigureFreeBuffers, instead of ConfigureBuffers
|
|
(which takes place in the function ngene_command_config_buf(), above).
|
|
|
|
Fix this by enclosing those 6 members of struct FW_CONFIGURE_FREE_BUFFERS
|
|
into new struct config, and use &com.cmd.ConfigureFreeBuffers.config as
|
|
the destination address, instead of &com.cmd.ConfigureBuffers.config,
|
|
when calling memcpy().
|
|
|
|
This also helps with the ongoing efforts to globally enable
|
|
-Warray-bounds and get us closer to being able to tighten the
|
|
FORTIFY_SOURCE routines on memcpy().(CVE-2021-47288)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
coresight: tmc-etf: Fix global-out-of-bounds in tmc_update_etf_buffer()
|
|
|
|
commit 6f755e85c332 ("coresight: Add helper for inserting synchronization
|
|
packets") removed trailing '\0' from barrier_pkt array and updated the
|
|
call sites like etb_update_buffer() to have proper checks for barrier_pkt
|
|
size before read but missed updating tmc_update_etf_buffer() which still
|
|
reads barrier_pkt past the array size resulting in KASAN out-of-bounds
|
|
bug. Fix this by adding a check for barrier_pkt size before accessing
|
|
like it is done in etb_update_buffer().
|
|
|
|
BUG: KASAN: global-out-of-bounds in tmc_update_etf_buffer+0x4b8/0x698
|
|
Read of size 4 at addr ffffffd05b7d1030 by task perf/2629
|
|
|
|
Call trace:
|
|
dump_backtrace+0x0/0x27c
|
|
show_stack+0x20/0x2c
|
|
dump_stack+0x11c/0x188
|
|
print_address_description+0x3c/0x4a4
|
|
__kasan_report+0x140/0x164
|
|
kasan_report+0x10/0x18
|
|
__asan_report_load4_noabort+0x1c/0x24
|
|
tmc_update_etf_buffer+0x4b8/0x698
|
|
etm_event_stop+0x248/0x2d8
|
|
etm_event_del+0x20/0x2c
|
|
event_sched_out+0x214/0x6f0
|
|
group_sched_out+0xd0/0x270
|
|
ctx_sched_out+0x2ec/0x518
|
|
__perf_event_task_sched_out+0x4fc/0xe6c
|
|
__schedule+0x1094/0x16a0
|
|
preempt_schedule_irq+0x88/0x170
|
|
arm64_preempt_schedule_irq+0xf0/0x18c
|
|
el1_irq+0xe8/0x180
|
|
perf_event_exec+0x4d8/0x56c
|
|
setup_new_exec+0x204/0x400
|
|
load_elf_binary+0x72c/0x18c0
|
|
search_binary_handler+0x13c/0x420
|
|
load_script+0x500/0x6c4
|
|
search_binary_handler+0x13c/0x420
|
|
exec_binprm+0x118/0x654
|
|
__do_execve_file+0x77c/0xba4
|
|
__arm64_compat_sys_execve+0x98/0xac
|
|
el0_svc_common+0x1f8/0x5e0
|
|
el0_svc_compat_handler+0x84/0xb0
|
|
el0_svc_compat+0x10/0x50
|
|
|
|
The buggy address belongs to the variable:
|
|
barrier_pkt+0x10/0x40
|
|
|
|
Memory state around the buggy address:
|
|
ffffffd05b7d0f00: fa fa fa fa 04 fa fa fa fa fa fa fa 00 00 00 00
|
|
ffffffd05b7d0f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
|
>ffffffd05b7d1000: 00 00 00 00 00 00 fa fa fa fa fa fa 00 00 00 03
|
|
^
|
|
ffffffd05b7d1080: fa fa fa fa 00 02 fa fa fa fa fa fa 03 fa fa fa
|
|
ffffffd05b7d1100: fa fa fa fa 00 00 00 00 05 fa fa fa fa fa fa fa
|
|
==================================================================(CVE-2021-47346)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wl1251: Fix possible buffer overflow in wl1251_cmd_scan
|
|
|
|
Function wl1251_cmd_scan calls memcpy without checking the length.
|
|
Harden by checking the length is within the maximum allowed size.(CVE-2021-47347)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
xhci: Fix command ring pointer corruption while aborting a command
|
|
|
|
The command ring pointer is located at [6:63] bits of the command
|
|
ring control register (CRCR). All the control bits like command stop,
|
|
abort are located at [0:3] bits. While aborting a command, we read the
|
|
CRCR and set the abort bit and write to the CRCR. The read will always
|
|
give command ring pointer as all zeros. So we essentially write only
|
|
the control bits. Since we split the 64 bit write into two 32 bit writes,
|
|
there is a possibility of xHC command ring stopped before the upper
|
|
dword (all zeros) is written. If that happens, xHC updates the upper
|
|
dword of its internal command ring pointer with all zeros. Next time,
|
|
when the command ring is restarted, we see xHC memory access failures.
|
|
Fix this issue by only writing to the lower dword of CRCR where all
|
|
control bits are located.(CVE-2021-47434)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
mm, slub: fix potential memoryleak in kmem_cache_open()
|
|
|
|
In error path, the random_seq of slub cache might be leaked. Fix this
|
|
by using __kmem_cache_release() to release all the relevant resources.(CVE-2021-47466)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
spi: Fix deadlock when adding SPI controllers on SPI buses
|
|
|
|
Currently we have a global spi_add_lock which we take when adding new
|
|
devices so that we can check that we're not trying to reuse a chip
|
|
select that's already controlled. This means that if the SPI device is
|
|
itself a SPI controller and triggers the instantiation of further SPI
|
|
devices we trigger a deadlock as we try to register and instantiate
|
|
those devices while in the process of doing so for the parent controller
|
|
and hence already holding the global spi_add_lock. Since we only care
|
|
about concurrency within a single SPI bus move the lock to be per
|
|
controller, avoiding the deadlock.
|
|
|
|
This can be easily triggered in the case of spi-mux.(CVE-2021-47469)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ocfs2: fix race between searching chunks and release journal_head from buffer_head
|
|
|
|
Encountered a race between ocfs2_test_bg_bit_allocatable() and
|
|
jbd2_journal_put_journal_head() resulting in the below vmcore.
|
|
|
|
PID: 106879 TASK: ffff880244ba9c00 CPU: 2 COMMAND: "loop3"
|
|
Call trace:
|
|
panic
|
|
oops_end
|
|
no_context
|
|
__bad_area_nosemaphore
|
|
bad_area_nosemaphore
|
|
__do_page_fault
|
|
do_page_fault
|
|
page_fault
|
|
[exception RIP: ocfs2_block_group_find_clear_bits+316]
|
|
ocfs2_block_group_find_clear_bits [ocfs2]
|
|
ocfs2_cluster_group_search [ocfs2]
|
|
ocfs2_search_chain [ocfs2]
|
|
ocfs2_claim_suballoc_bits [ocfs2]
|
|
__ocfs2_claim_clusters [ocfs2]
|
|
ocfs2_claim_clusters [ocfs2]
|
|
ocfs2_local_alloc_slide_window [ocfs2]
|
|
ocfs2_reserve_local_alloc_bits [ocfs2]
|
|
ocfs2_reserve_clusters_with_limit [ocfs2]
|
|
ocfs2_reserve_clusters [ocfs2]
|
|
ocfs2_lock_refcount_allocators [ocfs2]
|
|
ocfs2_make_clusters_writable [ocfs2]
|
|
ocfs2_replace_cow [ocfs2]
|
|
ocfs2_refcount_cow [ocfs2]
|
|
ocfs2_file_write_iter [ocfs2]
|
|
lo_rw_aio
|
|
loop_queue_work
|
|
kthread_worker_fn
|
|
kthread
|
|
ret_from_fork
|
|
|
|
When ocfs2_test_bg_bit_allocatable() called bh2jh(bg_bh), the
|
|
bg_bh->b_private NULL as jbd2_journal_put_journal_head() raced and
|
|
released the jounal head from the buffer head. Needed to take bit lock
|
|
for the bit 'BH_JournalHead' to fix this race.(CVE-2021-47493)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
iio: mma8452: Fix trigger reference couting
|
|
|
|
The mma8452 driver directly assigns a trigger to the struct iio_dev. The
|
|
IIO core when done using this trigger will call `iio_trigger_put()` to drop
|
|
the reference count by 1.
|
|
|
|
Without the matching `iio_trigger_get()` in the driver the reference count
|
|
can reach 0 too early, the trigger gets freed while still in use and a
|
|
use-after-free occurs.
|
|
|
|
Fix this by getting a reference to the trigger before assigning it to the
|
|
IIO device.(CVE-2021-47500)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
can: sja1000: fix use after free in ems_pcmcia_add_card()
|
|
|
|
If the last channel is not available then "dev" is freed. Fortunately,
|
|
we can just use "pdev->irq" instead.
|
|
|
|
Also we should check if at least one channel was set up.(CVE-2021-47521)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
scsi: mpt3sas: Fix kernel panic during drive powercycle test
|
|
|
|
While looping over shost's sdev list it is possible that one
|
|
of the drives is getting removed and its sas_target object is
|
|
freed but its sdev object remains intact.
|
|
|
|
Consequently, a kernel panic can occur while the driver is trying to access
|
|
the sas_address field of sas_target object without also checking the
|
|
sas_target object for NULL.(CVE-2021-47565)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
inet_diag: fix kernel-infoleak for UDP sockets
|
|
|
|
KMSAN reported a kernel-infoleak [1], that can exploited
|
|
by unpriv users.
|
|
|
|
After analysis it turned out UDP was not initializing
|
|
r->idiag_expires. Other users of inet_sk_diag_fill()
|
|
might make the same mistake in the future, so fix this
|
|
in inet_sk_diag_fill().
|
|
|
|
[1]
|
|
BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:121 [inline]
|
|
BUG: KMSAN: kernel-infoleak in copyout lib/iov_iter.c:156 [inline]
|
|
BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x69d/0x25c0 lib/iov_iter.c:670
|
|
instrument_copy_to_user include/linux/instrumented.h:121 [inline]
|
|
copyout lib/iov_iter.c:156 [inline]
|
|
_copy_to_iter+0x69d/0x25c0 lib/iov_iter.c:670
|
|
copy_to_iter include/linux/uio.h:155 [inline]
|
|
simple_copy_to_iter+0xf3/0x140 net/core/datagram.c:519
|
|
__skb_datagram_iter+0x2cb/0x1280 net/core/datagram.c:425
|
|
skb_copy_datagram_iter+0xdc/0x270 net/core/datagram.c:533
|
|
skb_copy_datagram_msg include/linux/skbuff.h:3657 [inline]
|
|
netlink_recvmsg+0x660/0x1c60 net/netlink/af_netlink.c:1974
|
|
sock_recvmsg_nosec net/socket.c:944 [inline]
|
|
sock_recvmsg net/socket.c:962 [inline]
|
|
sock_read_iter+0x5a9/0x630 net/socket.c:1035
|
|
call_read_iter include/linux/fs.h:2156 [inline]
|
|
new_sync_read fs/read_write.c:400 [inline]
|
|
vfs_read+0x1631/0x1980 fs/read_write.c:481
|
|
ksys_read+0x28c/0x520 fs/read_write.c:619
|
|
__do_sys_read fs/read_write.c:629 [inline]
|
|
__se_sys_read fs/read_write.c:627 [inline]
|
|
__x64_sys_read+0xdb/0x120 fs/read_write.c:627
|
|
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
|
|
do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82
|
|
entry_SYSCALL_64_after_hwframe+0x44/0xae
|
|
|
|
Uninit was created at:
|
|
slab_post_alloc_hook mm/slab.h:524 [inline]
|
|
slab_alloc_node mm/slub.c:3251 [inline]
|
|
__kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974
|
|
kmalloc_reserve net/core/skbuff.c:354 [inline]
|
|
__alloc_skb+0x545/0xf90 net/core/skbuff.c:426
|
|
alloc_skb include/linux/skbuff.h:1126 [inline]
|
|
netlink_dump+0x3d5/0x16a0 net/netlink/af_netlink.c:2245
|
|
__netlink_dump_start+0xd1c/0xee0 net/netlink/af_netlink.c:2370
|
|
netlink_dump_start include/linux/netlink.h:254 [inline]
|
|
inet_diag_handler_cmd+0x2e7/0x400 net/ipv4/inet_diag.c:1343
|
|
sock_diag_rcv_msg+0x24a/0x620
|
|
netlink_rcv_skb+0x447/0x800 net/netlink/af_netlink.c:2491
|
|
sock_diag_rcv+0x63/0x80 net/core/sock_diag.c:276
|
|
netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
|
|
netlink_unicast+0x1095/0x1360 net/netlink/af_netlink.c:1345
|
|
netlink_sendmsg+0x16f3/0x1870 net/netlink/af_netlink.c:1916
|
|
sock_sendmsg_nosec net/socket.c:704 [inline]
|
|
sock_sendmsg net/socket.c:724 [inline]
|
|
sock_write_iter+0x594/0x690 net/socket.c:1057
|
|
do_iter_readv_writev+0xa7f/0xc70
|
|
do_iter_write+0x52c/0x1500 fs/read_write.c:851
|
|
vfs_writev fs/read_write.c:924 [inline]
|
|
do_writev+0x63f/0xe30 fs/read_write.c:967
|
|
__do_sys_writev fs/read_write.c:1040 [inline]
|
|
__se_sys_writev fs/read_write.c:1037 [inline]
|
|
__x64_sys_writev+0xe5/0x120 fs/read_write.c:1037
|
|
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
|
|
do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82
|
|
entry_SYSCALL_64_after_hwframe+0x44/0xae
|
|
|
|
Bytes 68-71 of 312 are uninitialized
|
|
Memory access of size 312 starts at ffff88812ab54000
|
|
Data copied to user address 0000000020001440
|
|
|
|
CPU: 1 PID: 6365 Comm: syz-executor801 Not tainted 5.16.0-rc3-syzkaller #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011(CVE-2021-47597)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
firmware: arm_scpi: Fix string overflow in SCPI genpd driver
|
|
|
|
Without the bound checks for scpi_pd->name, it could result in the buffer
|
|
overflow when copying the SCPI device name from the corresponding device
|
|
tree node as the name string is set at maximum size of 30.
|
|
|
|
Let us fix it by using devm_kasprintf so that the string buffer is
|
|
allocated dynamically.(CVE-2021-47609)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ASoC: ops: Reject out of bounds values in snd_soc_put_volsw_sx()
|
|
|
|
We don't currently validate that the values being set are within the range
|
|
we advertised to userspace as being valid, do so and reject any values
|
|
that are out of range.(CVE-2022-48737)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
powerpc64/bpf: Limit 'ldbrx' to processors compliant with ISA v2.06
|
|
|
|
Johan reported the below crash with test_bpf on ppc64 e5500:
|
|
|
|
test_bpf: #296 ALU_END_FROM_LE 64: 0x0123456789abcdef -> 0x67452301 jited:1
|
|
Oops: Exception in kernel mode, sig: 4 [#1]
|
|
BE PAGE_SIZE=4K SMP NR_CPUS=24 QEMU e500
|
|
Modules linked in: test_bpf(+)
|
|
CPU: 0 PID: 76 Comm: insmod Not tainted 5.14.0-03771-g98c2059e008a-dirty #1
|
|
NIP: 8000000000061c3c LR: 80000000006dea64 CTR: 8000000000061c18
|
|
REGS: c0000000032d3420 TRAP: 0700 Not tainted (5.14.0-03771-g98c2059e008a-dirty)
|
|
MSR: 0000000080089000 <EE,ME> CR: 88002822 XER: 20000000 IRQMASK: 0
|
|
<...>
|
|
NIP [8000000000061c3c] 0x8000000000061c3c
|
|
LR [80000000006dea64] .__run_one+0x104/0x17c [test_bpf]
|
|
Call Trace:
|
|
.__run_one+0x60/0x17c [test_bpf] (unreliable)
|
|
.test_bpf_init+0x6a8/0xdc8 [test_bpf]
|
|
.do_one_initcall+0x6c/0x28c
|
|
.do_init_module+0x68/0x28c
|
|
.load_module+0x2460/0x2abc
|
|
.__do_sys_init_module+0x120/0x18c
|
|
.system_call_exception+0x110/0x1b8
|
|
system_call_common+0xf0/0x210
|
|
--- interrupt: c00 at 0x101d0acc
|
|
<...>
|
|
---[ end trace 47b2bf19090bb3d0 ]---
|
|
|
|
Illegal instruction
|
|
|
|
The illegal instruction turned out to be 'ldbrx' emitted for
|
|
BPF_FROM_[L|B]E, which was only introduced in ISA v2.06. Guard use of
|
|
the same and implement an alternative approach for older processors.(CVE-2022-48755)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/msm/dsi: invalid parameter check in msm_dsi_phy_enable
|
|
|
|
The function performs a check on the "phy" input parameter, however, it
|
|
is used before the check.
|
|
|
|
Initialize the "dev" variable after the sanity check to avoid a possible
|
|
NULL pointer dereference.
|
|
|
|
Addresses-Coverity-ID: 1493860 ("Null pointer dereference")(CVE-2022-48756)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
rpmsg: virtio: Free driver_override when rpmsg_remove()
|
|
|
|
Free driver_override when rpmsg_remove(), otherwise
|
|
the following memory leak will occur:
|
|
|
|
unreferenced object 0xffff0000d55d7080 (size 128):
|
|
comm "kworker/u8:2", pid 56, jiffies 4294893188 (age 214.272s)
|
|
hex dump (first 32 bytes):
|
|
72 70 6d 73 67 5f 6e 73 00 00 00 00 00 00 00 00 rpmsg_ns........
|
|
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
backtrace:
|
|
[<000000009c94c9c1>] __kmem_cache_alloc_node+0x1f8/0x320
|
|
[<000000002300d89b>] __kmalloc_node_track_caller+0x44/0x70
|
|
[<00000000228a60c3>] kstrndup+0x4c/0x90
|
|
[<0000000077158695>] driver_set_override+0xd0/0x164
|
|
[<000000003e9c4ea5>] rpmsg_register_device_override+0x98/0x170
|
|
[<000000001c0c89a8>] rpmsg_ns_register_device+0x24/0x30
|
|
[<000000008bbf8fa2>] rpmsg_probe+0x2e0/0x3ec
|
|
[<00000000e65a68df>] virtio_dev_probe+0x1c0/0x280
|
|
[<00000000443331cc>] really_probe+0xbc/0x2dc
|
|
[<00000000391064b1>] __driver_probe_device+0x78/0xe0
|
|
[<00000000a41c9a5b>] driver_probe_device+0xd8/0x160
|
|
[<000000009c3bd5df>] __device_attach_driver+0xb8/0x140
|
|
[<0000000043cd7614>] bus_for_each_drv+0x7c/0xd4
|
|
[<000000003b929a36>] __device_attach+0x9c/0x19c
|
|
[<00000000a94e0ba8>] device_initial_probe+0x14/0x20
|
|
[<000000003c999637>] bus_probe_device+0xa0/0xac(CVE-2023-52670)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
Fix page corruption caused by racy check in __free_pages
|
|
|
|
When we upgraded our kernel, we started seeing some page corruption like
|
|
the following consistently:
|
|
|
|
BUG: Bad page state in process ganesha.nfsd pfn:1304ca
|
|
page:0000000022261c55 refcount:0 mapcount:-128 mapping:0000000000000000 index:0x0 pfn:0x1304ca
|
|
flags: 0x17ffffc0000000()
|
|
raw: 0017ffffc0000000 ffff8a513ffd4c98 ffffeee24b35ec08 0000000000000000
|
|
raw: 0000000000000000 0000000000000001 00000000ffffff7f 0000000000000000
|
|
page dumped because: nonzero mapcount
|
|
CPU: 0 PID: 15567 Comm: ganesha.nfsd Kdump: loaded Tainted: P B O 5.10.158-1.nutanix.20221209.el7.x86_64 #1
|
|
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 04/05/2016
|
|
Call Trace:
|
|
dump_stack+0x74/0x96
|
|
bad_page.cold+0x63/0x94
|
|
check_new_page_bad+0x6d/0x80
|
|
rmqueue+0x46e/0x970
|
|
get_page_from_freelist+0xcb/0x3f0
|
|
? _cond_resched+0x19/0x40
|
|
__alloc_pages_nodemask+0x164/0x300
|
|
alloc_pages_current+0x87/0xf0
|
|
skb_page_frag_refill+0x84/0x110
|
|
...
|
|
|
|
Sometimes, it would also show up as corruption in the free list pointer
|
|
and cause crashes.
|
|
|
|
After bisecting the issue, we found the issue started from commit
|
|
e320d3012d25 ("mm/page_alloc.c: fix freeing non-compound pages"):
|
|
|
|
if (put_page_testzero(page))
|
|
free_the_page(page, order);
|
|
else if (!PageHead(page))
|
|
while (order-- > 0)
|
|
free_the_page(page + (1 << order), order);
|
|
|
|
So the problem is the check PageHead is racy because at this point we
|
|
already dropped our reference to the page. So even if we came in with
|
|
compound page, the page can already be freed and PageHead can return
|
|
false and we will end up freeing all the tail pages causing double free.(CVE-2023-52739)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
atl1c: Work around the DMA RX overflow issue
|
|
|
|
This is based on alx driver commit 881d0327db37 ("net: alx: Work around
|
|
the DMA RX overflow issue").
|
|
|
|
The alx and atl1c drivers had RX overflow error which was why a custom
|
|
allocator was created to avoid certain addresses. The simpler workaround
|
|
then created for alx driver, but not for atl1c due to lack of tester.
|
|
|
|
Instead of using a custom allocator, check the allocated skb address and
|
|
use skb_reserve() to move away from problematic 0x...fc0 address.
|
|
|
|
Tested on AR8131 on Acer 4540.(CVE-2023-52834)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
hid: cp2112: Fix duplicate workqueue initialization
|
|
|
|
Previously the cp2112 driver called INIT_DELAYED_WORK within
|
|
cp2112_gpio_irq_startup, resulting in duplicate initilizations of the
|
|
workqueue on subsequent IRQ startups following an initial request. This
|
|
resulted in a warning in set_work_data in workqueue.c, as well as a rare
|
|
NULL dereference within process_one_work in workqueue.c.
|
|
|
|
Initialize the workqueue within _probe instead.(CVE-2023-52853)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ALSA: usb-audio: Stop parsing channels bits when all channels are found.
|
|
|
|
If a usb audio device sets more bits than the amount of channels
|
|
it could write outside of the map array.(CVE-2024-27436)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
media: tc358743: register v4l2 async device only after successful setup
|
|
|
|
Ensure the device has been setup correctly before registering the v4l2
|
|
async device, thus allowing userspace to access.(CVE-2024-35830)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
usb: gadget: f_fs: Fix race between aio_cancel() and AIO request complete
|
|
|
|
FFS based applications can utilize the aio_cancel() callback to dequeue
|
|
pending USB requests submitted to the UDC. There is a scenario where the
|
|
FFS application issues an AIO cancel call, while the UDC is handling a
|
|
soft disconnect. For a DWC3 based implementation, the callstack looks
|
|
like the following:
|
|
|
|
DWC3 Gadget FFS Application
|
|
dwc3_gadget_soft_disconnect() ...
|
|
--> dwc3_stop_active_transfers()
|
|
--> dwc3_gadget_giveback(-ESHUTDOWN)
|
|
--> ffs_epfile_async_io_complete() ffs_aio_cancel()
|
|
--> usb_ep_free_request() --> usb_ep_dequeue()
|
|
|
|
There is currently no locking implemented between the AIO completion
|
|
handler and AIO cancel, so the issue occurs if the completion routine is
|
|
running in parallel to an AIO cancel call coming from the FFS application.
|
|
As the completion call frees the USB request (io_data->req) the FFS
|
|
application is also referencing it for the usb_ep_dequeue() call. This can
|
|
lead to accessing a stale/hanging pointer.
|
|
|
|
commit b566d38857fc ("usb: gadget: f_fs: use io_data->status consistently")
|
|
relocated the usb_ep_free_request() into ffs_epfile_async_io_complete().
|
|
However, in order to properly implement locking to mitigate this issue, the
|
|
spinlock can't be added to ffs_epfile_async_io_complete(), as
|
|
usb_ep_dequeue() (if successfully dequeuing a USB request) will call the
|
|
function driver's completion handler in the same context. Hence, leading
|
|
into a deadlock.
|
|
|
|
Fix this issue by moving the usb_ep_free_request() back to
|
|
ffs_user_copy_worker(), and ensuring that it explicitly sets io_data->req
|
|
to NULL after freeing it within the ffs->eps_lock. This resolves the race
|
|
condition above, as the ffs_aio_cancel() routine will not continue
|
|
attempting to dequeue a request that has already been freed, or the
|
|
ffs_user_copy_work() not freeing the USB request until the AIO cancel is
|
|
done referencing it.
|
|
|
|
This fix depends on
|
|
commit b566d38857fc ("usb: gadget: f_fs: use io_data->status
|
|
consistently")(CVE-2024-36894)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: nl80211: don't free NULL coalescing rule
|
|
|
|
If the parsing fails, we can dereference a NULL pointer here.(CVE-2024-36941)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
firewire: ohci: mask bus reset interrupts between ISR and bottom half
|
|
|
|
In the FireWire OHCI interrupt handler, if a bus reset interrupt has
|
|
occurred, mask bus reset interrupts until bus_reset_work has serviced and
|
|
cleared the interrupt.
|
|
|
|
Normally, we always leave bus reset interrupts masked. We infer the bus
|
|
reset from the self-ID interrupt that happens shortly thereafter. A
|
|
scenario where we unmask bus reset interrupts was introduced in 2008 in
|
|
a007bb857e0b26f5d8b73c2ff90782d9c0972620: If
|
|
OHCI_PARAM_DEBUG_BUSRESETS (8) is set in the debug parameter bitmask, we
|
|
will unmask bus reset interrupts so we can log them.
|
|
|
|
irq_handler logs the bus reset interrupt. However, we can't clear the bus
|
|
reset event flag in irq_handler, because we won't service the event until
|
|
later. irq_handler exits with the event flag still set. If the
|
|
corresponding interrupt is still unmasked, the first bus reset will
|
|
usually freeze the system due to irq_handler being called again each
|
|
time it exits. This freeze can be reproduced by loading firewire_ohci
|
|
with "modprobe firewire_ohci debug=-1" (to enable all debugging output).
|
|
Apparently there are also some cases where bus_reset_work will get called
|
|
soon enough to clear the event, and operation will continue normally.
|
|
|
|
This freeze was first reported a few months after a007bb85 was committed,
|
|
but until now it was never fixed. The debug level could safely be set
|
|
to -1 through sysfs after the module was loaded, but this would be
|
|
ineffectual in logging bus reset interrupts since they were only
|
|
unmasked during initialization.
|
|
|
|
irq_handler will now leave the event flag set but mask bus reset
|
|
interrupts, so irq_handler won't be called again and there will be no
|
|
freeze. If OHCI_PARAM_DEBUG_BUSRESETS is enabled, bus_reset_work will
|
|
unmask the interrupt after servicing the event, so future interrupts
|
|
will be caught as desired.
|
|
|
|
As a side effect to this change, OHCI_PARAM_DEBUG_BUSRESETS can now be
|
|
enabled through sysfs in addition to during initial module loading.
|
|
However, when enabled through sysfs, logging of bus reset interrupts will
|
|
be effective only starting with the second bus reset, after
|
|
bus_reset_work has executed.(CVE-2024-36950)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: fix __dst_negative_advice() race
|
|
|
|
__dst_negative_advice() does not enforce proper RCU rules when
|
|
sk->dst_cache must be cleared, leading to possible UAF.
|
|
|
|
RCU rules are that we must first clear sk->sk_dst_cache,
|
|
then call dst_release(old_dst).
|
|
|
|
Note that sk_dst_reset(sk) is implementing this protocol correctly,
|
|
while __dst_negative_advice() uses the wrong order.
|
|
|
|
Given that ip6_negative_advice() has special logic
|
|
against RTF_CACHE, this means each of the three ->negative_advice()
|
|
existing methods must perform the sk_dst_reset() themselves.
|
|
|
|
Note the check against NULL dst is centralized in
|
|
__dst_negative_advice(), there is no need to duplicate
|
|
it in various callbacks.
|
|
|
|
Many thanks to Clement Lecigne for tracking this issue.
|
|
|
|
This old bug became visible after the blamed commit, using UDP sockets.(CVE-2024-36971)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: bridge: xmit: make sure we have at least eth header len bytes
|
|
|
|
syzbot triggered an uninit value[1] error in bridge device's xmit path
|
|
by sending a short (less than ETH_HLEN bytes) skb. To fix it check if
|
|
we can actually pull that amount instead of assuming.
|
|
|
|
Tested with dropwatch:
|
|
drop at: br_dev_xmit+0xb93/0x12d0 [bridge] (0xffffffffc06739b3)
|
|
origin: software
|
|
timestamp: Mon May 13 11:31:53 2024 778214037 nsec
|
|
protocol: 0x88a8
|
|
length: 2
|
|
original length: 2
|
|
drop reason: PKT_TOO_SMALL
|
|
|
|
[1]
|
|
BUG: KMSAN: uninit-value in br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65
|
|
br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65
|
|
__netdev_start_xmit include/linux/netdevice.h:4903 [inline]
|
|
netdev_start_xmit include/linux/netdevice.h:4917 [inline]
|
|
xmit_one net/core/dev.c:3531 [inline]
|
|
dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547
|
|
__dev_queue_xmit+0x34db/0x5350 net/core/dev.c:4341
|
|
dev_queue_xmit include/linux/netdevice.h:3091 [inline]
|
|
__bpf_tx_skb net/core/filter.c:2136 [inline]
|
|
__bpf_redirect_common net/core/filter.c:2180 [inline]
|
|
__bpf_redirect+0x14a6/0x1620 net/core/filter.c:2187
|
|
____bpf_clone_redirect net/core/filter.c:2460 [inline]
|
|
bpf_clone_redirect+0x328/0x470 net/core/filter.c:2432
|
|
___bpf_prog_run+0x13fe/0xe0f0 kernel/bpf/core.c:1997
|
|
__bpf_prog_run512+0xb5/0xe0 kernel/bpf/core.c:2238
|
|
bpf_dispatcher_nop_func include/linux/bpf.h:1234 [inline]
|
|
__bpf_prog_run include/linux/filter.h:657 [inline]
|
|
bpf_prog_run include/linux/filter.h:664 [inline]
|
|
bpf_test_run+0x499/0xc30 net/bpf/test_run.c:425
|
|
bpf_prog_test_run_skb+0x14ea/0x1f20 net/bpf/test_run.c:1058
|
|
bpf_prog_test_run+0x6b7/0xad0 kernel/bpf/syscall.c:4269
|
|
__sys_bpf+0x6aa/0xd90 kernel/bpf/syscall.c:5678
|
|
__do_sys_bpf kernel/bpf/syscall.c:5767 [inline]
|
|
__se_sys_bpf kernel/bpf/syscall.c:5765 [inline]
|
|
__x64_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5765
|
|
x64_sys_call+0x96b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:322
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-38538)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
of: module: add buffer overflow check in of_modalias()
|
|
|
|
In of_modalias(), if the buffer happens to be too small even for the 1st
|
|
snprintf() call, the len parameter will become negative and str parameter
|
|
(if not NULL initially) will point beyond the buffer's end. Add the buffer
|
|
overflow check after the 1st snprintf() call and fix such check after the
|
|
strlen() call (accounting for the terminating NUL char).(CVE-2024-38541)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/amd/display: Fix potential index out of bounds in color transformation function
|
|
|
|
Fixes index out of bounds issue in the color transformation function.
|
|
The issue could occur when the index 'i' exceeds the number of transfer
|
|
function points (TRANSFER_FUNC_POINTS).
|
|
|
|
The fix adds a check to ensure 'i' is within bounds before accessing the
|
|
transfer function points. If 'i' is out of bounds, an error message is
|
|
logged and the function returns false to indicate an error.
|
|
|
|
Reported by smatch:
|
|
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:405 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max
|
|
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:406 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max
|
|
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:407 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max(CVE-2024-38552)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ftrace: Fix possible use-after-free issue in ftrace_location()
|
|
|
|
KASAN reports a bug:
|
|
|
|
BUG: KASAN: use-after-free in ftrace_location+0x90/0x120
|
|
Read of size 8 at addr ffff888141d40010 by task insmod/424
|
|
CPU: 8 PID: 424 Comm: insmod Tainted: G W 6.9.0-rc2+
|
|
[...]
|
|
Call Trace:
|
|
<TASK>
|
|
dump_stack_lvl+0x68/0xa0
|
|
print_report+0xcf/0x610
|
|
kasan_report+0xb5/0xe0
|
|
ftrace_location+0x90/0x120
|
|
register_kprobe+0x14b/0xa40
|
|
kprobe_init+0x2d/0xff0 [kprobe_example]
|
|
do_one_initcall+0x8f/0x2d0
|
|
do_init_module+0x13a/0x3c0
|
|
load_module+0x3082/0x33d0
|
|
init_module_from_file+0xd2/0x130
|
|
__x64_sys_finit_module+0x306/0x440
|
|
do_syscall_64+0x68/0x140
|
|
entry_SYSCALL_64_after_hwframe+0x71/0x79
|
|
|
|
The root cause is that, in lookup_rec(), ftrace record of some address
|
|
is being searched in ftrace pages of some module, but those ftrace pages
|
|
at the same time is being freed in ftrace_release_mod() as the
|
|
corresponding module is being deleted:
|
|
|
|
CPU1 | CPU2
|
|
register_kprobes() { | delete_module() {
|
|
check_kprobe_address_safe() { |
|
|
arch_check_ftrace_location() { |
|
|
ftrace_location() { |
|
|
lookup_rec() // USE! | ftrace_release_mod() // Free!
|
|
|
|
To fix this issue:
|
|
1. Hold rcu lock as accessing ftrace pages in ftrace_location_range();
|
|
2. Use ftrace_location_range() instead of lookup_rec() in
|
|
ftrace_location();
|
|
3. Call synchronize_rcu() before freeing any ftrace pages both in
|
|
ftrace_process_locs()/ftrace_release_mod()/ftrace_free_mem().(CVE-2024-38588)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
af_unix: Fix data races in unix_release_sock/unix_stream_sendmsg
|
|
|
|
A data-race condition has been identified in af_unix. In one data path,
|
|
the write function unix_release_sock() atomically writes to
|
|
sk->sk_shutdown using WRITE_ONCE. However, on the reader side,
|
|
unix_stream_sendmsg() does not read it atomically. Consequently, this
|
|
issue is causing the following KCSAN splat to occur:
|
|
|
|
BUG: KCSAN: data-race in unix_release_sock / unix_stream_sendmsg
|
|
|
|
write (marked) to 0xffff88867256ddbb of 1 bytes by task 7270 on cpu 28:
|
|
unix_release_sock (net/unix/af_unix.c:640)
|
|
unix_release (net/unix/af_unix.c:1050)
|
|
sock_close (net/socket.c:659 net/socket.c:1421)
|
|
__fput (fs/file_table.c:422)
|
|
__fput_sync (fs/file_table.c:508)
|
|
__se_sys_close (fs/open.c:1559 fs/open.c:1541)
|
|
__x64_sys_close (fs/open.c:1541)
|
|
x64_sys_call (arch/x86/entry/syscall_64.c:33)
|
|
do_syscall_64 (arch/x86/entry/common.c:?)
|
|
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
|
|
|
|
read to 0xffff88867256ddbb of 1 bytes by task 989 on cpu 14:
|
|
unix_stream_sendmsg (net/unix/af_unix.c:2273)
|
|
__sock_sendmsg (net/socket.c:730 net/socket.c:745)
|
|
____sys_sendmsg (net/socket.c:2584)
|
|
__sys_sendmmsg (net/socket.c:2638 net/socket.c:2724)
|
|
__x64_sys_sendmmsg (net/socket.c:2753 net/socket.c:2750 net/socket.c:2750)
|
|
x64_sys_call (arch/x86/entry/syscall_64.c:33)
|
|
do_syscall_64 (arch/x86/entry/common.c:?)
|
|
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
|
|
|
|
value changed: 0x01 -> 0x03
|
|
|
|
The line numbers are related to commit dd5a440a31fa ("Linux 6.9-rc7").
|
|
|
|
Commit e1d09c2c2f57 ("af_unix: Fix data races around sk->sk_shutdown.")
|
|
addressed a comparable issue in the past regarding sk->sk_shutdown.
|
|
However, it overlooked resolving this particular data path.
|
|
This patch only offending unix_stream_sendmsg() function, since the
|
|
other reads seem to be protected by unix_state_lock() as discussed in(CVE-2024-38596)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
macintosh/via-macii: Fix "BUG: sleeping function called from invalid context"
|
|
|
|
The via-macii ADB driver calls request_irq() after disabling hard
|
|
interrupts. But disabling interrupts isn't necessary here because the
|
|
VIA shift register interrupt was masked during VIA1 initialization.(CVE-2024-38607)</Note>
|
|
<Note Title="Topic" Type="General" Ordinal="4" xml:lang="en">An update for kernel is now available for openEuler-20.03-LTS-SP4.
|
|
|
|
openEuler Security has rated this update as having a security impact of high. A Common Vunlnerability Scoring System(CVSS)base score,which gives a detailed severity rating, is available for each vulnerability from the CVElink(s) in the References section.</Note>
|
|
<Note Title="Severity" Type="General" Ordinal="5" xml:lang="en">High</Note>
|
|
<Note Title="Affected Component" Type="General" Ordinal="6" xml:lang="en">kernel</Note>
|
|
</DocumentNotes>
|
|
<DocumentReferences>
|
|
<Reference Type="Self">
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1767</URL>
|
|
</Reference>
|
|
<Reference Type="openEuler CVE">
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47231</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47232</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47252</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47288</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47346</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47347</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47434</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47466</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47469</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47493</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47500</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47521</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47565</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47597</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47609</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2022-48737</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2022-48755</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2022-48756</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52670</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52739</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52834</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52853</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27436</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35830</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-36894</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-36941</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-36950</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-36971</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-38538</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-38541</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-38552</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-38588</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-38596</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-38607</URL>
|
|
</Reference>
|
|
<Reference Type="Other">
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47231</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47232</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47252</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47288</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47346</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47347</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47434</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47466</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47469</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47493</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47500</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47521</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47565</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47597</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47609</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48737</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48755</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48756</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52670</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52739</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52834</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52853</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27436</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35830</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36894</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36941</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36950</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36971</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38538</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38541</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38552</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38588</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38596</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-38607</URL>
|
|
</Reference>
|
|
</DocumentReferences>
|
|
<ProductTree xmlns="http://www.icasi.org/CVRF/schema/prod/1.1">
|
|
<Branch Type="Product Name" Name="openEuler">
|
|
<FullProductName ProductID="openEuler-20.03-LTS-SP4" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">openEuler-20.03-LTS-SP4</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="aarch64">
|
|
<FullProductName ProductID="perf-debuginfo-4.19.90-2406.4.0.0283" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-debuginfo-4.19.90-2406.4.0.0283.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-4.19.90-2406.4.0.0283" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debugsource-4.19.90-2406.4.0.0283.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-4.19.90-2406.4.0.0283" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-4.19.90-2406.4.0.0283.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-debuginfo-4.19.90-2406.4.0.0283" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-debuginfo-4.19.90-2406.4.0.0283.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-4.19.90-2406.4.0.0283" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-4.19.90-2406.4.0.0283.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-4.19.90-2406.4.0.0283" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-debuginfo-4.19.90-2406.4.0.0283.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-4.19.90-2406.4.0.0283" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-source-4.19.90-2406.4.0.0283.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-4.19.90-2406.4.0.0283" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debuginfo-4.19.90-2406.4.0.0283.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-4.19.90-2406.4.0.0283" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-4.19.90-2406.4.0.0283.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-4.19.90-2406.4.0.0283" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-4.19.90-2406.4.0.0283.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-4.19.90-2406.4.0.0283" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-debuginfo-4.19.90-2406.4.0.0283.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-4.19.90-2406.4.0.0283" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-devel-4.19.90-2406.4.0.0283.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-4.19.90-2406.4.0.0283" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-4.19.90-2406.4.0.0283.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-debuginfo-4.19.90-2406.4.0.0283" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-debuginfo-4.19.90-2406.4.0.0283.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-4.19.90-2406.4.0.0283" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-4.19.90-2406.4.0.0283.oe2003sp4.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-4.19.90-2406.4.0.0283" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-devel-4.19.90-2406.4.0.0283.oe2003sp4.aarch64.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="src">
|
|
<FullProductName ProductID="kernel-4.19.90-2406.4.0.0283" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-4.19.90-2406.4.0.0283.oe2003sp4.src.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="x86_64">
|
|
<FullProductName ProductID="perf-debuginfo-4.19.90-2406.4.0.0283" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-debuginfo-4.19.90-2406.4.0.0283.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-4.19.90-2406.4.0.0283" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-devel-4.19.90-2406.4.0.0283.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-4.19.90-2406.4.0.0283" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-4.19.90-2406.4.0.0283.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-4.19.90-2406.4.0.0283" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">perf-4.19.90-2406.4.0.0283.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-4.19.90-2406.4.0.0283" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-4.19.90-2406.4.0.0283.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-debuginfo-4.19.90-2406.4.0.0283" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-debuginfo-4.19.90-2406.4.0.0283.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-4.19.90-2406.4.0.0283" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-source-4.19.90-2406.4.0.0283.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python2-perf-4.19.90-2406.4.0.0283" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python2-perf-4.19.90-2406.4.0.0283.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-4.19.90-2406.4.0.0283" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-debuginfo-4.19.90-2406.4.0.0283.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-4.19.90-2406.4.0.0283" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-4.19.90-2406.4.0.0283.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-4.19.90-2406.4.0.0283" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-debuginfo-4.19.90-2406.4.0.0283.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="bpftool-debuginfo-4.19.90-2406.4.0.0283" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">bpftool-debuginfo-4.19.90-2406.4.0.0283.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-4.19.90-2406.4.0.0283" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debuginfo-4.19.90-2406.4.0.0283.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-4.19.90-2406.4.0.0283" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-tools-devel-4.19.90-2406.4.0.0283.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-4.19.90-2406.4.0.0283" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">kernel-debugsource-4.19.90-2406.4.0.0283.oe2003sp4.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-4.19.90-2406.4.0.0283" CPE="cpe:/a:openEuler:openEuler:20.03-LTS-SP4">python3-perf-4.19.90-2406.4.0.0283.oe2003sp4.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:
|
|
|
|
can: mcba_usb: fix memory leak in mcba_usb
|
|
|
|
Syzbot reported memory leak in SocketCAN driver for Microchip CAN BUS
|
|
Analyzer Tool. The problem was in unfreed usb_coherent.
|
|
|
|
In mcba_usb_start() 20 coherent buffers are allocated and there is
|
|
nothing, that frees them:
|
|
|
|
1) In callback function the urb is resubmitted and that's all
|
|
2) In disconnect function urbs are simply killed, but URB_FREE_BUFFER
|
|
is not set (see mcba_usb_start) and this flag cannot be used with
|
|
coherent buffers.
|
|
|
|
Fail log:
|
|
| [ 1354.053291][ T8413] mcba_usb 1-1:0.0 can0: device disconnected
|
|
| [ 1367.059384][ T8420] kmemleak: 20 new suspected memory leaks (see /sys/kernel/debug/kmem)
|
|
|
|
So, all allocated buffers should be freed with usb_free_coherent()
|
|
explicitly
|
|
|
|
NOTE:
|
|
The same pattern for allocating and freeing coherent buffers
|
|
is used in drivers/net/can/usb/kvaser_usb/kvaser_usb_core.c</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2021-47231</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>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-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1767</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:
|
|
|
|
can: j1939: fix Use-after-Free, hold skb ref while in use
|
|
|
|
This patch fixes a Use-after-Free found by the syzbot.
|
|
|
|
The problem is that a skb is taken from the per-session skb queue,
|
|
without incrementing the ref count. This leads to a Use-after-Free if
|
|
the skb is taken concurrently from the session queue due to a CTS.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2021-47232</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>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-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1767</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:
|
|
|
|
batman-adv: Avoid WARN_ON timing related checks
|
|
|
|
The soft/batadv interface for a queued OGM can be changed during the time
|
|
the OGM was queued for transmission and when the OGM is actually
|
|
transmitted by the worker.
|
|
|
|
But WARN_ON must be used to denote kernel bugs and not to print simple
|
|
warnings. A warning can simply be printed using pr_warn.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2021-47252</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>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-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1767</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:
|
|
|
|
media: ngene: Fix out-of-bounds bug in ngene_command_config_free_buf()
|
|
|
|
Fix an 11-year old bug in ngene_command_config_free_buf() while
|
|
addressing the following warnings caught with -Warray-bounds:
|
|
|
|
arch/alpha/include/asm/string.h:22:16: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds]
|
|
arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds]
|
|
|
|
The problem is that the original code is trying to copy 6 bytes of
|
|
data into a one-byte size member _config_ of the wrong structue
|
|
FW_CONFIGURE_BUFFERS, in a single call to memcpy(). This causes a
|
|
legitimate compiler warning because memcpy() overruns the length
|
|
of &com.cmd.ConfigureBuffers.config. It seems that the right
|
|
structure is FW_CONFIGURE_FREE_BUFFERS, instead, because it contains
|
|
6 more members apart from the header _hdr_. Also, the name of
|
|
the function ngene_command_config_free_buf() suggests that the actual
|
|
intention is to ConfigureFreeBuffers, instead of ConfigureBuffers
|
|
(which takes place in the function ngene_command_config_buf(), above).
|
|
|
|
Fix this by enclosing those 6 members of struct FW_CONFIGURE_FREE_BUFFERS
|
|
into new struct config, and use &com.cmd.ConfigureFreeBuffers.config as
|
|
the destination address, instead of &com.cmd.ConfigureBuffers.config,
|
|
when calling memcpy().
|
|
|
|
This also helps with the ongoing efforts to globally enable
|
|
-Warray-bounds and get us closer to being able to tighten the
|
|
FORTIFY_SOURCE routines on memcpy().</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2021-47288</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>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-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1767</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:
|
|
|
|
coresight: tmc-etf: Fix global-out-of-bounds in tmc_update_etf_buffer()
|
|
|
|
commit 6f755e85c332 ("coresight: Add helper for inserting synchronization
|
|
packets") removed trailing '\0' from barrier_pkt array and updated the
|
|
call sites like etb_update_buffer() to have proper checks for barrier_pkt
|
|
size before read but missed updating tmc_update_etf_buffer() which still
|
|
reads barrier_pkt past the array size resulting in KASAN out-of-bounds
|
|
bug. Fix this by adding a check for barrier_pkt size before accessing
|
|
like it is done in etb_update_buffer().
|
|
|
|
BUG: KASAN: global-out-of-bounds in tmc_update_etf_buffer+0x4b8/0x698
|
|
Read of size 4 at addr ffffffd05b7d1030 by task perf/2629
|
|
|
|
Call trace:
|
|
dump_backtrace+0x0/0x27c
|
|
show_stack+0x20/0x2c
|
|
dump_stack+0x11c/0x188
|
|
print_address_description+0x3c/0x4a4
|
|
__kasan_report+0x140/0x164
|
|
kasan_report+0x10/0x18
|
|
__asan_report_load4_noabort+0x1c/0x24
|
|
tmc_update_etf_buffer+0x4b8/0x698
|
|
etm_event_stop+0x248/0x2d8
|
|
etm_event_del+0x20/0x2c
|
|
event_sched_out+0x214/0x6f0
|
|
group_sched_out+0xd0/0x270
|
|
ctx_sched_out+0x2ec/0x518
|
|
__perf_event_task_sched_out+0x4fc/0xe6c
|
|
__schedule+0x1094/0x16a0
|
|
preempt_schedule_irq+0x88/0x170
|
|
arm64_preempt_schedule_irq+0xf0/0x18c
|
|
el1_irq+0xe8/0x180
|
|
perf_event_exec+0x4d8/0x56c
|
|
setup_new_exec+0x204/0x400
|
|
load_elf_binary+0x72c/0x18c0
|
|
search_binary_handler+0x13c/0x420
|
|
load_script+0x500/0x6c4
|
|
search_binary_handler+0x13c/0x420
|
|
exec_binprm+0x118/0x654
|
|
__do_execve_file+0x77c/0xba4
|
|
__arm64_compat_sys_execve+0x98/0xac
|
|
el0_svc_common+0x1f8/0x5e0
|
|
el0_svc_compat_handler+0x84/0xb0
|
|
el0_svc_compat+0x10/0x50
|
|
|
|
The buggy address belongs to the variable:
|
|
barrier_pkt+0x10/0x40
|
|
|
|
Memory state around the buggy address:
|
|
ffffffd05b7d0f00: fa fa fa fa 04 fa fa fa fa fa fa fa 00 00 00 00
|
|
ffffffd05b7d0f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
|
>ffffffd05b7d1000: 00 00 00 00 00 00 fa fa fa fa fa fa 00 00 00 03
|
|
^
|
|
ffffffd05b7d1080: fa fa fa fa 00 02 fa fa fa fa fa fa 03 fa fa fa
|
|
ffffffd05b7d1100: fa fa fa fa 00 00 00 00 05 fa fa fa fa fa fa fa
|
|
==================================================================</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2021-47346</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>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-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1767</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:
|
|
|
|
wl1251: Fix possible buffer overflow in wl1251_cmd_scan
|
|
|
|
Function wl1251_cmd_scan calls memcpy without checking the length.
|
|
Harden by checking the length is within the maximum allowed size.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2021-47347</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>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-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1767</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:
|
|
|
|
xhci: Fix command ring pointer corruption while aborting a command
|
|
|
|
The command ring pointer is located at [6:63] bits of the command
|
|
ring control register (CRCR). All the control bits like command stop,
|
|
abort are located at [0:3] bits. While aborting a command, we read the
|
|
CRCR and set the abort bit and write to the CRCR. The read will always
|
|
give command ring pointer as all zeros. So we essentially write only
|
|
the control bits. Since we split the 64 bit write into two 32 bit writes,
|
|
there is a possibility of xHC command ring stopped before the upper
|
|
dword (all zeros) is written. If that happens, xHC updates the upper
|
|
dword of its internal command ring pointer with all zeros. Next time,
|
|
when the command ring is restarted, we see xHC memory access failures.
|
|
Fix this issue by only writing to the lower dword of CRCR where all
|
|
control bits are located.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2021-47434</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1767</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:
|
|
|
|
mm, slub: fix potential memoryleak in kmem_cache_open()
|
|
|
|
In error path, the random_seq of slub cache might be leaked. Fix this
|
|
by using __kmem_cache_release() to release all the relevant resources.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2021-47466</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.4</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-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1767</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:
|
|
|
|
spi: Fix deadlock when adding SPI controllers on SPI buses
|
|
|
|
Currently we have a global spi_add_lock which we take when adding new
|
|
devices so that we can check that we're not trying to reuse a chip
|
|
select that's already controlled. This means that if the SPI device is
|
|
itself a SPI controller and triggers the instantiation of further SPI
|
|
devices we trigger a deadlock as we try to register and instantiate
|
|
those devices while in the process of doing so for the parent controller
|
|
and hence already holding the global spi_add_lock. Since we only care
|
|
about concurrency within a single SPI bus move the lock to be per
|
|
controller, avoiding the deadlock.
|
|
|
|
This can be easily triggered in the case of spi-mux.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2021-47469</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1767</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:
|
|
|
|
ocfs2: fix race between searching chunks and release journal_head from buffer_head
|
|
|
|
Encountered a race between ocfs2_test_bg_bit_allocatable() and
|
|
jbd2_journal_put_journal_head() resulting in the below vmcore.
|
|
|
|
PID: 106879 TASK: ffff880244ba9c00 CPU: 2 COMMAND: "loop3"
|
|
Call trace:
|
|
panic
|
|
oops_end
|
|
no_context
|
|
__bad_area_nosemaphore
|
|
bad_area_nosemaphore
|
|
__do_page_fault
|
|
do_page_fault
|
|
page_fault
|
|
[exception RIP: ocfs2_block_group_find_clear_bits+316]
|
|
ocfs2_block_group_find_clear_bits [ocfs2]
|
|
ocfs2_cluster_group_search [ocfs2]
|
|
ocfs2_search_chain [ocfs2]
|
|
ocfs2_claim_suballoc_bits [ocfs2]
|
|
__ocfs2_claim_clusters [ocfs2]
|
|
ocfs2_claim_clusters [ocfs2]
|
|
ocfs2_local_alloc_slide_window [ocfs2]
|
|
ocfs2_reserve_local_alloc_bits [ocfs2]
|
|
ocfs2_reserve_clusters_with_limit [ocfs2]
|
|
ocfs2_reserve_clusters [ocfs2]
|
|
ocfs2_lock_refcount_allocators [ocfs2]
|
|
ocfs2_make_clusters_writable [ocfs2]
|
|
ocfs2_replace_cow [ocfs2]
|
|
ocfs2_refcount_cow [ocfs2]
|
|
ocfs2_file_write_iter [ocfs2]
|
|
lo_rw_aio
|
|
loop_queue_work
|
|
kthread_worker_fn
|
|
kthread
|
|
ret_from_fork
|
|
|
|
When ocfs2_test_bg_bit_allocatable() called bh2jh(bg_bh), the
|
|
bg_bh->b_private NULL as jbd2_journal_put_journal_head() raced and
|
|
released the jounal head from the buffer head. Needed to take bit lock
|
|
for the bit 'BH_JournalHead' to fix this race.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2021-47493</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>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-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1767</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:
|
|
|
|
iio: mma8452: Fix trigger reference couting
|
|
|
|
The mma8452 driver directly assigns a trigger to the struct iio_dev. The
|
|
IIO core when done using this trigger will call `iio_trigger_put()` to drop
|
|
the reference count by 1.
|
|
|
|
Without the matching `iio_trigger_get()` in the driver the reference count
|
|
can reach 0 too early, the trigger gets freed while still in use and a
|
|
use-after-free occurs.
|
|
|
|
Fix this by getting a reference to the trigger before assigning it to the
|
|
IIO device.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2021-47500</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>High</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>7.8</BaseScore>
|
|
<Vector>AV:L/AC:L/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-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1767</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:can: sja1000: fix use after free in ems_pcmcia_add_card()If the last channel is not available then dev is freed. Fortunately,we can just use pdev->irq instead.Also we should check if at least one channel was set up.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2021-47521</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>High</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>7.8</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-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1767</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:
|
|
|
|
scsi: mpt3sas: Fix kernel panic during drive powercycle test
|
|
|
|
While looping over shost's sdev list it is possible that one
|
|
of the drives is getting removed and its sas_target object is
|
|
freed but its sdev object remains intact.
|
|
|
|
Consequently, a kernel panic can occur while the driver is trying to access
|
|
the sas_address field of sas_target object without also checking the
|
|
sas_target object for NULL.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2021-47565</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>4.7</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-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1767</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:
|
|
|
|
inet_diag: fix kernel-infoleak for UDP sockets
|
|
|
|
KMSAN reported a kernel-infoleak [1], that can exploited
|
|
by unpriv users.
|
|
|
|
After analysis it turned out UDP was not initializing
|
|
r->idiag_expires. Other users of inet_sk_diag_fill()
|
|
might make the same mistake in the future, so fix this
|
|
in inet_sk_diag_fill().
|
|
|
|
[1]
|
|
BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:121 [inline]
|
|
BUG: KMSAN: kernel-infoleak in copyout lib/iov_iter.c:156 [inline]
|
|
BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x69d/0x25c0 lib/iov_iter.c:670
|
|
instrument_copy_to_user include/linux/instrumented.h:121 [inline]
|
|
copyout lib/iov_iter.c:156 [inline]
|
|
_copy_to_iter+0x69d/0x25c0 lib/iov_iter.c:670
|
|
copy_to_iter include/linux/uio.h:155 [inline]
|
|
simple_copy_to_iter+0xf3/0x140 net/core/datagram.c:519
|
|
__skb_datagram_iter+0x2cb/0x1280 net/core/datagram.c:425
|
|
skb_copy_datagram_iter+0xdc/0x270 net/core/datagram.c:533
|
|
skb_copy_datagram_msg include/linux/skbuff.h:3657 [inline]
|
|
netlink_recvmsg+0x660/0x1c60 net/netlink/af_netlink.c:1974
|
|
sock_recvmsg_nosec net/socket.c:944 [inline]
|
|
sock_recvmsg net/socket.c:962 [inline]
|
|
sock_read_iter+0x5a9/0x630 net/socket.c:1035
|
|
call_read_iter include/linux/fs.h:2156 [inline]
|
|
new_sync_read fs/read_write.c:400 [inline]
|
|
vfs_read+0x1631/0x1980 fs/read_write.c:481
|
|
ksys_read+0x28c/0x520 fs/read_write.c:619
|
|
__do_sys_read fs/read_write.c:629 [inline]
|
|
__se_sys_read fs/read_write.c:627 [inline]
|
|
__x64_sys_read+0xdb/0x120 fs/read_write.c:627
|
|
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
|
|
do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82
|
|
entry_SYSCALL_64_after_hwframe+0x44/0xae
|
|
|
|
Uninit was created at:
|
|
slab_post_alloc_hook mm/slab.h:524 [inline]
|
|
slab_alloc_node mm/slub.c:3251 [inline]
|
|
__kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974
|
|
kmalloc_reserve net/core/skbuff.c:354 [inline]
|
|
__alloc_skb+0x545/0xf90 net/core/skbuff.c:426
|
|
alloc_skb include/linux/skbuff.h:1126 [inline]
|
|
netlink_dump+0x3d5/0x16a0 net/netlink/af_netlink.c:2245
|
|
__netlink_dump_start+0xd1c/0xee0 net/netlink/af_netlink.c:2370
|
|
netlink_dump_start include/linux/netlink.h:254 [inline]
|
|
inet_diag_handler_cmd+0x2e7/0x400 net/ipv4/inet_diag.c:1343
|
|
sock_diag_rcv_msg+0x24a/0x620
|
|
netlink_rcv_skb+0x447/0x800 net/netlink/af_netlink.c:2491
|
|
sock_diag_rcv+0x63/0x80 net/core/sock_diag.c:276
|
|
netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
|
|
netlink_unicast+0x1095/0x1360 net/netlink/af_netlink.c:1345
|
|
netlink_sendmsg+0x16f3/0x1870 net/netlink/af_netlink.c:1916
|
|
sock_sendmsg_nosec net/socket.c:704 [inline]
|
|
sock_sendmsg net/socket.c:724 [inline]
|
|
sock_write_iter+0x594/0x690 net/socket.c:1057
|
|
do_iter_readv_writev+0xa7f/0xc70
|
|
do_iter_write+0x52c/0x1500 fs/read_write.c:851
|
|
vfs_writev fs/read_write.c:924 [inline]
|
|
do_writev+0x63f/0xe30 fs/read_write.c:967
|
|
__do_sys_writev fs/read_write.c:1040 [inline]
|
|
__se_sys_writev fs/read_write.c:1037 [inline]
|
|
__x64_sys_writev+0xe5/0x120 fs/read_write.c:1037
|
|
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
|
|
do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82
|
|
entry_SYSCALL_64_after_hwframe+0x44/0xae
|
|
|
|
Bytes 68-71 of 312 are uninitialized
|
|
Memory access of size 312 starts at ffff88812ab54000
|
|
Data copied to user address 0000000020001440
|
|
|
|
CPU: 1 PID: 6365 Comm: syz-executor801 Not tainted 5.16.0-rc3-syzkaller #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2021-47597</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>3.3</BaseScore>
|
|
<Vector>AV:L/AC: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-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1767</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:
|
|
|
|
firmware: arm_scpi: Fix string overflow in SCPI genpd driver
|
|
|
|
Without the bound checks for scpi_pd->name, it could result in the buffer
|
|
overflow when copying the SCPI device name from the corresponding device
|
|
tree node as the name string is set at maximum size of 30.
|
|
|
|
Let us fix it by using devm_kasprintf so that the string buffer is
|
|
allocated dynamically.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2021-47609</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1767</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:
|
|
|
|
ASoC: ops: Reject out of bounds values in snd_soc_put_volsw_sx()
|
|
|
|
We don't currently validate that the values being set are within the range
|
|
we advertised to userspace as being valid, do so and reject any values
|
|
that are out of range.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2022-48737</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.3</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-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1767</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:
|
|
|
|
powerpc64/bpf: Limit 'ldbrx' to processors compliant with ISA v2.06
|
|
|
|
Johan reported the below crash with test_bpf on ppc64 e5500:
|
|
|
|
test_bpf: #296 ALU_END_FROM_LE 64: 0x0123456789abcdef -> 0x67452301 jited:1
|
|
Oops: Exception in kernel mode, sig: 4 [#1]
|
|
BE PAGE_SIZE=4K SMP NR_CPUS=24 QEMU e500
|
|
Modules linked in: test_bpf(+)
|
|
CPU: 0 PID: 76 Comm: insmod Not tainted 5.14.0-03771-g98c2059e008a-dirty #1
|
|
NIP: 8000000000061c3c LR: 80000000006dea64 CTR: 8000000000061c18
|
|
REGS: c0000000032d3420 TRAP: 0700 Not tainted (5.14.0-03771-g98c2059e008a-dirty)
|
|
MSR: 0000000080089000 <EE,ME> CR: 88002822 XER: 20000000 IRQMASK: 0
|
|
<...>
|
|
NIP [8000000000061c3c] 0x8000000000061c3c
|
|
LR [80000000006dea64] .__run_one+0x104/0x17c [test_bpf]
|
|
Call Trace:
|
|
.__run_one+0x60/0x17c [test_bpf] (unreliable)
|
|
.test_bpf_init+0x6a8/0xdc8 [test_bpf]
|
|
.do_one_initcall+0x6c/0x28c
|
|
.do_init_module+0x68/0x28c
|
|
.load_module+0x2460/0x2abc
|
|
.__do_sys_init_module+0x120/0x18c
|
|
.system_call_exception+0x110/0x1b8
|
|
system_call_common+0xf0/0x210
|
|
--- interrupt: c00 at 0x101d0acc
|
|
<...>
|
|
---[ end trace 47b2bf19090bb3d0 ]---
|
|
|
|
Illegal instruction
|
|
|
|
The illegal instruction turned out to be 'ldbrx' emitted for
|
|
BPF_FROM_[L|B]E, which was only introduced in ISA v2.06. Guard use of
|
|
the same and implement an alternative approach for older processors.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2022-48755</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1767</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:
|
|
|
|
drm/msm/dsi: invalid parameter check in msm_dsi_phy_enable
|
|
|
|
The function performs a check on the "phy" input parameter, however, it
|
|
is used before the check.
|
|
|
|
Initialize the "dev" variable after the sanity check to avoid a possible
|
|
NULL pointer dereference.
|
|
|
|
Addresses-Coverity-ID: 1493860 ("Null pointer dereference")</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2022-48756</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>0.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-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1767</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:
|
|
|
|
rpmsg: virtio: Free driver_override when rpmsg_remove()
|
|
|
|
Free driver_override when rpmsg_remove(), otherwise
|
|
the following memory leak will occur:
|
|
|
|
unreferenced object 0xffff0000d55d7080 (size 128):
|
|
comm "kworker/u8:2", pid 56, jiffies 4294893188 (age 214.272s)
|
|
hex dump (first 32 bytes):
|
|
72 70 6d 73 67 5f 6e 73 00 00 00 00 00 00 00 00 rpmsg_ns........
|
|
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
backtrace:
|
|
[<000000009c94c9c1>] __kmem_cache_alloc_node+0x1f8/0x320
|
|
[<000000002300d89b>] __kmalloc_node_track_caller+0x44/0x70
|
|
[<00000000228a60c3>] kstrndup+0x4c/0x90
|
|
[<0000000077158695>] driver_set_override+0xd0/0x164
|
|
[<000000003e9c4ea5>] rpmsg_register_device_override+0x98/0x170
|
|
[<000000001c0c89a8>] rpmsg_ns_register_device+0x24/0x30
|
|
[<000000008bbf8fa2>] rpmsg_probe+0x2e0/0x3ec
|
|
[<00000000e65a68df>] virtio_dev_probe+0x1c0/0x280
|
|
[<00000000443331cc>] really_probe+0xbc/0x2dc
|
|
[<00000000391064b1>] __driver_probe_device+0x78/0xe0
|
|
[<00000000a41c9a5b>] driver_probe_device+0xd8/0x160
|
|
[<000000009c3bd5df>] __device_attach_driver+0xb8/0x140
|
|
[<0000000043cd7614>] bus_for_each_drv+0x7c/0xd4
|
|
[<000000003b929a36>] __device_attach+0x9c/0x19c
|
|
[<00000000a94e0ba8>] device_initial_probe+0x14/0x20
|
|
[<000000003c999637>] bus_probe_device+0xa0/0xac</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2023-52670</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1767</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:
|
|
|
|
Fix page corruption caused by racy check in __free_pages
|
|
|
|
When we upgraded our kernel, we started seeing some page corruption like
|
|
the following consistently:
|
|
|
|
BUG: Bad page state in process ganesha.nfsd pfn:1304ca
|
|
page:0000000022261c55 refcount:0 mapcount:-128 mapping:0000000000000000 index:0x0 pfn:0x1304ca
|
|
flags: 0x17ffffc0000000()
|
|
raw: 0017ffffc0000000 ffff8a513ffd4c98 ffffeee24b35ec08 0000000000000000
|
|
raw: 0000000000000000 0000000000000001 00000000ffffff7f 0000000000000000
|
|
page dumped because: nonzero mapcount
|
|
CPU: 0 PID: 15567 Comm: ganesha.nfsd Kdump: loaded Tainted: P B O 5.10.158-1.nutanix.20221209.el7.x86_64 #1
|
|
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 04/05/2016
|
|
Call Trace:
|
|
dump_stack+0x74/0x96
|
|
bad_page.cold+0x63/0x94
|
|
check_new_page_bad+0x6d/0x80
|
|
rmqueue+0x46e/0x970
|
|
get_page_from_freelist+0xcb/0x3f0
|
|
? _cond_resched+0x19/0x40
|
|
__alloc_pages_nodemask+0x164/0x300
|
|
alloc_pages_current+0x87/0xf0
|
|
skb_page_frag_refill+0x84/0x110
|
|
...
|
|
|
|
Sometimes, it would also show up as corruption in the free list pointer
|
|
and cause crashes.
|
|
|
|
After bisecting the issue, we found the issue started from commit
|
|
e320d3012d25 ("mm/page_alloc.c: fix freeing non-compound pages"):
|
|
|
|
if (put_page_testzero(page))
|
|
free_the_page(page, order);
|
|
else if (!PageHead(page))
|
|
while (order-- > 0)
|
|
free_the_page(page + (1 << order), order);
|
|
|
|
So the problem is the check PageHead is racy because at this point we
|
|
already dropped our reference to the page. So even if we came in with
|
|
compound page, the page can already be freed and PageHead can return
|
|
false and we will end up freeing all the tail pages causing double free.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2023-52739</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>High</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>7.0</BaseScore>
|
|
<Vector>AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1767</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:
|
|
|
|
atl1c: Work around the DMA RX overflow issue
|
|
|
|
This is based on alx driver commit 881d0327db37 ("net: alx: Work around
|
|
the DMA RX overflow issue").
|
|
|
|
The alx and atl1c drivers had RX overflow error which was why a custom
|
|
allocator was created to avoid certain addresses. The simpler workaround
|
|
then created for alx driver, but not for atl1c due to lack of tester.
|
|
|
|
Instead of using a custom allocator, check the allocated skb address and
|
|
use skb_reserve() to move away from problematic 0x...fc0 address.
|
|
|
|
Tested on AR8131 on Acer 4540.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2023-52834</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1767</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:
|
|
|
|
hid: cp2112: Fix duplicate workqueue initialization
|
|
|
|
Previously the cp2112 driver called INIT_DELAYED_WORK within
|
|
cp2112_gpio_irq_startup, resulting in duplicate initilizations of the
|
|
workqueue on subsequent IRQ startups following an initial request. This
|
|
resulted in a warning in set_work_data in workqueue.c, as well as a rare
|
|
NULL dereference within process_one_work in workqueue.c.
|
|
|
|
Initialize the workqueue within _probe instead.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2023-52853</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>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-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1767</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:
|
|
|
|
ALSA: usb-audio: Stop parsing channels bits when all channels are found.
|
|
|
|
If a usb audio device sets more bits than the amount of channels
|
|
it could write outside of the map array.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-27436</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1767</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:
|
|
|
|
media: tc358743: register v4l2 async device only after successful setup
|
|
|
|
Ensure the device has been setup correctly before registering the v4l2
|
|
async device, thus allowing userspace to access.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-35830</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>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-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1767</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:
|
|
|
|
usb: gadget: f_fs: Fix race between aio_cancel() and AIO request complete
|
|
|
|
FFS based applications can utilize the aio_cancel() callback to dequeue
|
|
pending USB requests submitted to the UDC. There is a scenario where the
|
|
FFS application issues an AIO cancel call, while the UDC is handling a
|
|
soft disconnect. For a DWC3 based implementation, the callstack looks
|
|
like the following:
|
|
|
|
DWC3 Gadget FFS Application
|
|
dwc3_gadget_soft_disconnect() ...
|
|
--> dwc3_stop_active_transfers()
|
|
--> dwc3_gadget_giveback(-ESHUTDOWN)
|
|
--> ffs_epfile_async_io_complete() ffs_aio_cancel()
|
|
--> usb_ep_free_request() --> usb_ep_dequeue()
|
|
|
|
There is currently no locking implemented between the AIO completion
|
|
handler and AIO cancel, so the issue occurs if the completion routine is
|
|
running in parallel to an AIO cancel call coming from the FFS application.
|
|
As the completion call frees the USB request (io_data->req) the FFS
|
|
application is also referencing it for the usb_ep_dequeue() call. This can
|
|
lead to accessing a stale/hanging pointer.
|
|
|
|
commit b566d38857fc ("usb: gadget: f_fs: use io_data->status consistently")
|
|
relocated the usb_ep_free_request() into ffs_epfile_async_io_complete().
|
|
However, in order to properly implement locking to mitigate this issue, the
|
|
spinlock can't be added to ffs_epfile_async_io_complete(), as
|
|
usb_ep_dequeue() (if successfully dequeuing a USB request) will call the
|
|
function driver's completion handler in the same context. Hence, leading
|
|
into a deadlock.
|
|
|
|
Fix this issue by moving the usb_ep_free_request() back to
|
|
ffs_user_copy_worker(), and ensuring that it explicitly sets io_data->req
|
|
to NULL after freeing it within the ffs->eps_lock. This resolves the race
|
|
condition above, as the ffs_aio_cancel() routine will not continue
|
|
attempting to dequeue a request that has already been freed, or the
|
|
ffs_user_copy_work() not freeing the USB request until the AIO cancel is
|
|
done referencing it.
|
|
|
|
This fix depends on
|
|
commit b566d38857fc ("usb: gadget: f_fs: use io_data->status
|
|
consistently")</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-36894</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>0.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-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1767</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:
|
|
|
|
wifi: nl80211: don't free NULL coalescing rule
|
|
|
|
If the parsing fails, we can dereference a NULL pointer here.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-36941</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1767</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:
|
|
|
|
firewire: ohci: mask bus reset interrupts between ISR and bottom half
|
|
|
|
In the FireWire OHCI interrupt handler, if a bus reset interrupt has
|
|
occurred, mask bus reset interrupts until bus_reset_work has serviced and
|
|
cleared the interrupt.
|
|
|
|
Normally, we always leave bus reset interrupts masked. We infer the bus
|
|
reset from the self-ID interrupt that happens shortly thereafter. A
|
|
scenario where we unmask bus reset interrupts was introduced in 2008 in
|
|
a007bb857e0b26f5d8b73c2ff90782d9c0972620: If
|
|
OHCI_PARAM_DEBUG_BUSRESETS (8) is set in the debug parameter bitmask, we
|
|
will unmask bus reset interrupts so we can log them.
|
|
|
|
irq_handler logs the bus reset interrupt. However, we can't clear the bus
|
|
reset event flag in irq_handler, because we won't service the event until
|
|
later. irq_handler exits with the event flag still set. If the
|
|
corresponding interrupt is still unmasked, the first bus reset will
|
|
usually freeze the system due to irq_handler being called again each
|
|
time it exits. This freeze can be reproduced by loading firewire_ohci
|
|
with "modprobe firewire_ohci debug=-1" (to enable all debugging output).
|
|
Apparently there are also some cases where bus_reset_work will get called
|
|
soon enough to clear the event, and operation will continue normally.
|
|
|
|
This freeze was first reported a few months after a007bb85 was committed,
|
|
but until now it was never fixed. The debug level could safely be set
|
|
to -1 through sysfs after the module was loaded, but this would be
|
|
ineffectual in logging bus reset interrupts since they were only
|
|
unmasked during initialization.
|
|
|
|
irq_handler will now leave the event flag set but mask bus reset
|
|
interrupts, so irq_handler won't be called again and there will be no
|
|
freeze. If OHCI_PARAM_DEBUG_BUSRESETS is enabled, bus_reset_work will
|
|
unmask the interrupt after servicing the event, so future interrupts
|
|
will be caught as desired.
|
|
|
|
As a side effect to this change, OHCI_PARAM_DEBUG_BUSRESETS can now be
|
|
enabled through sysfs in addition to during initial module loading.
|
|
However, when enabled through sysfs, logging of bus reset interrupts will
|
|
be effective only starting with the second bus reset, after
|
|
bus_reset_work has executed.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-36950</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1767</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="28" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="28" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:net: fix __dst_negative_advice() race__dst_negative_advice() does not enforce proper RCU rules whensk->dst_cache must be cleared, leading to possible UAF.RCU rules are that we must first clear sk->sk_dst_cache,then call dst_release(old_dst).Note that sk_dst_reset(sk) is implementing this protocol correctly,while __dst_negative_advice() uses the wrong order.Given that ip6_negative_advice() has special logicagainst RTF_CACHE, this means each of the three ->negative_advice()existing methods must perform the sk_dst_reset() themselves.Note the check against NULL dst is centralized in__dst_negative_advice(), there is no need to duplicateit in various callbacks.Many thanks to Clement Lecigne for tracking this issue.This old bug became visible after the blamed commit, using UDP sockets.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-36971</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>High</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>7.8</BaseScore>
|
|
<Vector>AV:L/AC:L/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-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1767</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="29" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="29" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: bridge: xmit: make sure we have at least eth header len bytes
|
|
|
|
syzbot triggered an uninit value[1] error in bridge device's xmit path
|
|
by sending a short (less than ETH_HLEN bytes) skb. To fix it check if
|
|
we can actually pull that amount instead of assuming.
|
|
|
|
Tested with dropwatch:
|
|
drop at: br_dev_xmit+0xb93/0x12d0 [bridge] (0xffffffffc06739b3)
|
|
origin: software
|
|
timestamp: Mon May 13 11:31:53 2024 778214037 nsec
|
|
protocol: 0x88a8
|
|
length: 2
|
|
original length: 2
|
|
drop reason: PKT_TOO_SMALL
|
|
|
|
[1]
|
|
BUG: KMSAN: uninit-value in br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65
|
|
br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65
|
|
__netdev_start_xmit include/linux/netdevice.h:4903 [inline]
|
|
netdev_start_xmit include/linux/netdevice.h:4917 [inline]
|
|
xmit_one net/core/dev.c:3531 [inline]
|
|
dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547
|
|
__dev_queue_xmit+0x34db/0x5350 net/core/dev.c:4341
|
|
dev_queue_xmit include/linux/netdevice.h:3091 [inline]
|
|
__bpf_tx_skb net/core/filter.c:2136 [inline]
|
|
__bpf_redirect_common net/core/filter.c:2180 [inline]
|
|
__bpf_redirect+0x14a6/0x1620 net/core/filter.c:2187
|
|
____bpf_clone_redirect net/core/filter.c:2460 [inline]
|
|
bpf_clone_redirect+0x328/0x470 net/core/filter.c:2432
|
|
___bpf_prog_run+0x13fe/0xe0f0 kernel/bpf/core.c:1997
|
|
__bpf_prog_run512+0xb5/0xe0 kernel/bpf/core.c:2238
|
|
bpf_dispatcher_nop_func include/linux/bpf.h:1234 [inline]
|
|
__bpf_prog_run include/linux/filter.h:657 [inline]
|
|
bpf_prog_run include/linux/filter.h:664 [inline]
|
|
bpf_test_run+0x499/0xc30 net/bpf/test_run.c:425
|
|
bpf_prog_test_run_skb+0x14ea/0x1f20 net/bpf/test_run.c:1058
|
|
bpf_prog_test_run+0x6b7/0xad0 kernel/bpf/syscall.c:4269
|
|
__sys_bpf+0x6aa/0xd90 kernel/bpf/syscall.c:5678
|
|
__do_sys_bpf kernel/bpf/syscall.c:5767 [inline]
|
|
__se_sys_bpf kernel/bpf/syscall.c:5765 [inline]
|
|
__x64_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5765
|
|
x64_sys_call+0x96b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:322
|
|
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
|
|
do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
|
|
entry_SYSCALL_64_after_hwframe+0x77/0x7f</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-38538</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1767</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="30" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="30" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
of: module: add buffer overflow check in of_modalias()
|
|
|
|
In of_modalias(), if the buffer happens to be too small even for the 1st
|
|
snprintf() call, the len parameter will become negative and str parameter
|
|
(if not NULL initially) will point beyond the buffer's end. Add the buffer
|
|
overflow check after the 1st snprintf() call and fix such check after the
|
|
strlen() call (accounting for the terminating NUL char).</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-38541</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1767</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="31" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="31" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/amd/display: Fix potential index out of bounds in color transformation function
|
|
|
|
Fixes index out of bounds issue in the color transformation function.
|
|
The issue could occur when the index 'i' exceeds the number of transfer
|
|
function points (TRANSFER_FUNC_POINTS).
|
|
|
|
The fix adds a check to ensure 'i' is within bounds before accessing the
|
|
transfer function points. If 'i' is out of bounds, an error message is
|
|
logged and the function returns false to indicate an error.
|
|
|
|
Reported by smatch:
|
|
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:405 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max
|
|
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:406 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max
|
|
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:407 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-38552</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>6.1</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-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1767</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="32" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="32" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ftrace: Fix possible use-after-free issue in ftrace_location()
|
|
|
|
KASAN reports a bug:
|
|
|
|
BUG: KASAN: use-after-free in ftrace_location+0x90/0x120
|
|
Read of size 8 at addr ffff888141d40010 by task insmod/424
|
|
CPU: 8 PID: 424 Comm: insmod Tainted: G W 6.9.0-rc2+
|
|
[...]
|
|
Call Trace:
|
|
<TASK>
|
|
dump_stack_lvl+0x68/0xa0
|
|
print_report+0xcf/0x610
|
|
kasan_report+0xb5/0xe0
|
|
ftrace_location+0x90/0x120
|
|
register_kprobe+0x14b/0xa40
|
|
kprobe_init+0x2d/0xff0 [kprobe_example]
|
|
do_one_initcall+0x8f/0x2d0
|
|
do_init_module+0x13a/0x3c0
|
|
load_module+0x3082/0x33d0
|
|
init_module_from_file+0xd2/0x130
|
|
__x64_sys_finit_module+0x306/0x440
|
|
do_syscall_64+0x68/0x140
|
|
entry_SYSCALL_64_after_hwframe+0x71/0x79
|
|
|
|
The root cause is that, in lookup_rec(), ftrace record of some address
|
|
is being searched in ftrace pages of some module, but those ftrace pages
|
|
at the same time is being freed in ftrace_release_mod() as the
|
|
corresponding module is being deleted:
|
|
|
|
CPU1 | CPU2
|
|
register_kprobes() { | delete_module() {
|
|
check_kprobe_address_safe() { |
|
|
arch_check_ftrace_location() { |
|
|
ftrace_location() { |
|
|
lookup_rec() // USE! | ftrace_release_mod() // Free!
|
|
|
|
To fix this issue:
|
|
1. Hold rcu lock as accessing ftrace pages in ftrace_location_range();
|
|
2. Use ftrace_location_range() instead of lookup_rec() in
|
|
ftrace_location();
|
|
3. Call synchronize_rcu() before freeing any ftrace pages both in
|
|
ftrace_process_locs()/ftrace_release_mod()/ftrace_free_mem().</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-38588</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1767</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="33" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="33" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
af_unix: Fix data races in unix_release_sock/unix_stream_sendmsg
|
|
|
|
A data-race condition has been identified in af_unix. In one data path,
|
|
the write function unix_release_sock() atomically writes to
|
|
sk->sk_shutdown using WRITE_ONCE. However, on the reader side,
|
|
unix_stream_sendmsg() does not read it atomically. Consequently, this
|
|
issue is causing the following KCSAN splat to occur:
|
|
|
|
BUG: KCSAN: data-race in unix_release_sock / unix_stream_sendmsg
|
|
|
|
write (marked) to 0xffff88867256ddbb of 1 bytes by task 7270 on cpu 28:
|
|
unix_release_sock (net/unix/af_unix.c:640)
|
|
unix_release (net/unix/af_unix.c:1050)
|
|
sock_close (net/socket.c:659 net/socket.c:1421)
|
|
__fput (fs/file_table.c:422)
|
|
__fput_sync (fs/file_table.c:508)
|
|
__se_sys_close (fs/open.c:1559 fs/open.c:1541)
|
|
__x64_sys_close (fs/open.c:1541)
|
|
x64_sys_call (arch/x86/entry/syscall_64.c:33)
|
|
do_syscall_64 (arch/x86/entry/common.c:?)
|
|
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
|
|
|
|
read to 0xffff88867256ddbb of 1 bytes by task 989 on cpu 14:
|
|
unix_stream_sendmsg (net/unix/af_unix.c:2273)
|
|
__sock_sendmsg (net/socket.c:730 net/socket.c:745)
|
|
____sys_sendmsg (net/socket.c:2584)
|
|
__sys_sendmmsg (net/socket.c:2638 net/socket.c:2724)
|
|
__x64_sys_sendmmsg (net/socket.c:2753 net/socket.c:2750 net/socket.c:2750)
|
|
x64_sys_call (arch/x86/entry/syscall_64.c:33)
|
|
do_syscall_64 (arch/x86/entry/common.c:?)
|
|
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
|
|
|
|
value changed: 0x01 -> 0x03
|
|
|
|
The line numbers are related to commit dd5a440a31fa ("Linux 6.9-rc7").
|
|
|
|
Commit e1d09c2c2f57 ("af_unix: Fix data races around sk->sk_shutdown.")
|
|
addressed a comparable issue in the past regarding sk->sk_shutdown.
|
|
However, it overlooked resolving this particular data path.
|
|
This patch only offending unix_stream_sendmsg() function, since the
|
|
other reads seem to be protected by unix_state_lock() as discussed in</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-38596</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>2.5</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-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1767</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="34" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="34" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
macintosh/via-macii: Fix "BUG: sleeping function called from invalid context"
|
|
|
|
The via-macii ADB driver calls request_irq() after disabling hard
|
|
interrupts. But disabling interrupts isn't necessary here because the
|
|
VIA shift register interrupt was masked during VIA1 initialization.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-28</ReleaseDate>
|
|
<CVE>CVE-2024-38607</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-20.03-LTS-SP4</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-06-28</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1767</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
</cvrfdoc> |