5157 lines
218 KiB
XML
5157 lines
218 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<cvrfdoc xmlns="http://www.icasi.org/CVRF/schema/cvrf/1.1" xmlns:cvrf="http://www.icasi.org/CVRF/schema/cvrf/1.1">
|
|
<DocumentTitle xml:lang="en">An update for kernel is now available for openEuler-22.03-LTS-SP3</DocumentTitle>
|
|
<DocumentType>Security Advisory</DocumentType>
|
|
<DocumentPublisher Type="Vendor">
|
|
<ContactDetails>openeuler-security@openeuler.org</ContactDetails>
|
|
<IssuingAuthority>openEuler security committee</IssuingAuthority>
|
|
</DocumentPublisher>
|
|
<DocumentTracking>
|
|
<Identification>
|
|
<ID>openEuler-SA-2024-1694</ID>
|
|
</Identification>
|
|
<Status>Final</Status>
|
|
<Version>1.0</Version>
|
|
<RevisionHistory>
|
|
<Revision>
|
|
<Number>1.0</Number>
|
|
<Date>2024-06-07</Date>
|
|
<Description>Initial</Description>
|
|
</Revision>
|
|
</RevisionHistory>
|
|
<InitialReleaseDate>2024-06-07</InitialReleaseDate>
|
|
<CurrentReleaseDate>2024-06-07</CurrentReleaseDate>
|
|
<Generator>
|
|
<Engine>openEuler SA Tool V1.0</Engine>
|
|
<Date>2024-06-07</Date>
|
|
</Generator>
|
|
</DocumentTracking>
|
|
<DocumentNotes>
|
|
<Note Title="Synopsis" Type="General" Ordinal="1" xml:lang="en">kernel security update</Note>
|
|
<Note Title="Summary" Type="General" Ordinal="2" xml:lang="en">An update for kernel is now available for openEuler-22.03-LTS-SP3.</Note>
|
|
<Note Title="Description" Type="General" Ordinal="3" xml:lang="en">The Linux Kernel, the operating system core itself.
|
|
|
|
Security Fix(es):
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
RDMA: Verify port when creating flow rule
|
|
|
|
Validate port value provided by the user and with that remove no longer
|
|
needed validation by the driver. The missing check in the mlx5_ib driver
|
|
could cause to the below oops.
|
|
|
|
Call trace:
|
|
_create_flow_rule+0x2d4/0xf28 [mlx5_ib]
|
|
mlx5_ib_create_flow+0x2d0/0x5b0 [mlx5_ib]
|
|
ib_uverbs_ex_create_flow+0x4cc/0x624 [ib_uverbs]
|
|
ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0xd4/0x150 [ib_uverbs]
|
|
ib_uverbs_cmd_verbs.isra.7+0xb28/0xc50 [ib_uverbs]
|
|
ib_uverbs_ioctl+0x158/0x1d0 [ib_uverbs]
|
|
do_vfs_ioctl+0xd0/0xaf0
|
|
ksys_ioctl+0x84/0xb4
|
|
__arm64_sys_ioctl+0x28/0xc4
|
|
el0_svc_common.constprop.3+0xa4/0x254
|
|
el0_svc_handler+0x84/0xa0
|
|
el0_svc+0x10/0x26c
|
|
Code: b9401260 f9615681 51000400 8b001c20 (f9403c1a)(CVE-2021-47265)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
mISDN: fix possible use-after-free in HFC_cleanup()
|
|
|
|
This module's remove path calls del_timer(). However, that function
|
|
does not wait until the timer handler finishes. This means that the
|
|
timer handler may still be running after the driver's remove function
|
|
has finished, which would result in a use-after-free.
|
|
|
|
Fix by calling del_timer_sync(), which makes sure the timer handler
|
|
has finished, and unable to re-schedule itself.(CVE-2021-47356)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
mptcp: ensure tx skbs always have the MPTCP ext
|
|
|
|
Due to signed/unsigned comparison, the expression:
|
|
|
|
info->size_goal - skb->len > 0
|
|
|
|
evaluates to true when the size goal is smaller than the
|
|
skb size. That results in lack of tx cache refill, so that
|
|
the skb allocated by the core TCP code lacks the required
|
|
MPTCP skb extensions.
|
|
|
|
Due to the above, syzbot is able to trigger the following WARN_ON():
|
|
|
|
WARNING: CPU: 1 PID: 810 at net/mptcp/protocol.c:1366 mptcp_sendmsg_frag+0x1362/0x1bc0 net/mptcp/protocol.c:1366
|
|
Modules linked in:
|
|
CPU: 1 PID: 810 Comm: syz-executor.4 Not tainted 5.14.0-syzkaller #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
|
|
RIP: 0010:mptcp_sendmsg_frag+0x1362/0x1bc0 net/mptcp/protocol.c:1366
|
|
Code: ff 4c 8b 74 24 50 48 8b 5c 24 58 e9 0f fb ff ff e8 13 44 8b f8 4c 89 e7 45 31 ed e8 98 57 2e fe e9 81 f4 ff ff e8 fe 43 8b f8 <0f> 0b 41 bd ea ff ff ff e9 6f f4 ff ff 4c 89 e7 e8 b9 8e d2 f8 e9
|
|
RSP: 0018:ffffc9000531f6a0 EFLAGS: 00010216
|
|
RAX: 000000000000697f RBX: 0000000000000000 RCX: ffffc90012107000
|
|
RDX: 0000000000040000 RSI: ffffffff88eac9e2 RDI: 0000000000000003
|
|
RBP: ffff888078b15780 R08: 0000000000000000 R09: 0000000000000000
|
|
R10: ffffffff88eac017 R11: 0000000000000000 R12: ffff88801de0a280
|
|
R13: 0000000000006b58 R14: ffff888066278280 R15: ffff88803c2fe9c0
|
|
FS: 00007fd9f866e700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 00007faebcb2f718 CR3: 00000000267cb000 CR4: 00000000001506e0
|
|
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
Call Trace:
|
|
__mptcp_push_pending+0x1fb/0x6b0 net/mptcp/protocol.c:1547
|
|
mptcp_release_cb+0xfe/0x210 net/mptcp/protocol.c:3003
|
|
release_sock+0xb4/0x1b0 net/core/sock.c:3206
|
|
sk_stream_wait_memory+0x604/0xed0 net/core/stream.c:145
|
|
mptcp_sendmsg+0xc39/0x1bc0 net/mptcp/protocol.c:1749
|
|
inet6_sendmsg+0x99/0xe0 net/ipv6/af_inet6.c:643
|
|
sock_sendmsg_nosec net/socket.c:704 [inline]
|
|
sock_sendmsg+0xcf/0x120 net/socket.c:724
|
|
sock_write_iter+0x2a0/0x3e0 net/socket.c:1057
|
|
call_write_iter include/linux/fs.h:2163 [inline]
|
|
new_sync_write+0x40b/0x640 fs/read_write.c:507
|
|
vfs_write+0x7cf/0xae0 fs/read_write.c:594
|
|
ksys_write+0x1ee/0x250 fs/read_write.c:647
|
|
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
|
|
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
|
|
entry_SYSCALL_64_after_hwframe+0x44/0xae
|
|
RIP: 0033:0x4665f9
|
|
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
|
|
RSP: 002b:00007fd9f866e188 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
|
|
RAX: ffffffffffffffda RBX: 000000000056c038 RCX: 00000000004665f9
|
|
RDX: 00000000000e7b78 RSI: 0000000020000000 RDI: 0000000000000003
|
|
RBP: 00000000004bfcc4 R08: 0000000000000000 R09: 0000000000000000
|
|
R10: 0000000000000000 R11: 0000000000000246 R12: 000000000056c038
|
|
R13: 0000000000a9fb1f R14: 00007fd9f866e300 R15: 0000000000022000
|
|
|
|
Fix the issue rewriting the relevant expression to avoid
|
|
sign-related problems - note: size_goal is always >= 0.
|
|
|
|
Additionally, ensure that the skb in the tx cache always carries
|
|
the relevant extension.(CVE-2021-47370)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
scsi: iscsi: Fix iscsi_task use after free
|
|
|
|
Commit d39df158518c ("scsi: iscsi: Have abort handler get ref to conn")
|
|
added iscsi_get_conn()/iscsi_put_conn() calls during abort handling but
|
|
then also changed the handling of the case where we detect an already
|
|
completed task where we now end up doing a goto to the common put/cleanup
|
|
code. This results in a iscsi_task use after free, because the common
|
|
cleanup code will do a put on the iscsi_task.
|
|
|
|
This reverts the goto and moves the iscsi_get_conn() to after we've checked
|
|
if the iscsi_task is valid.(CVE-2021-47427)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/amdgpu: Fix even more out of bound writes from debugfs
|
|
|
|
CVE-2021-42327 was fixed by:
|
|
|
|
commit f23750b5b3d98653b31d4469592935ef6364ad67
|
|
Author: Thelford Williams <tdwilliamsiv@gmail.com>
|
|
Date: Wed Oct 13 16:04:13 2021 -0400
|
|
|
|
drm/amdgpu: fix out of bounds write
|
|
|
|
but amdgpu_dm_debugfs.c contains more of the same issue so fix the
|
|
remaining ones.
|
|
|
|
v2:
|
|
* Add missing fix in dp_max_bpc_write (Harry Wentland)(CVE-2021-47489)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
tcp: TX zerocopy should not sense pfmemalloc status
|
|
|
|
We got a recent syzbot report [1] showing a possible misuse
|
|
of pfmemalloc page status in TCP zerocopy paths.
|
|
|
|
Indeed, for pages coming from user space or other layers,
|
|
using page_is_pfmemalloc() is moot, and possibly could give
|
|
false positives.
|
|
|
|
There has been attempts to make page_is_pfmemalloc() more robust,
|
|
but not using it in the first place in this context is probably better,
|
|
removing cpu cycles.
|
|
|
|
Note to stable teams :
|
|
|
|
You need to backport 84ce071e38a6 ("net: introduce
|
|
__skb_fill_page_desc_noacc") as a prereq.
|
|
|
|
Race is more probable after commit c07aea3ef4d4
|
|
("mm: add a signature in struct page") because page_is_pfmemalloc()
|
|
is now using low order bit from page->lru.next, which can change
|
|
more often than page->index.
|
|
|
|
Low order bit should never be set for lru.next (when used as an anchor
|
|
in LRU list), so KCSAN report is mostly a false positive.
|
|
|
|
Backporting to older kernel versions seems not necessary.
|
|
|
|
[1]
|
|
BUG: KCSAN: data-race in lru_add_fn / tcp_build_frag
|
|
|
|
write to 0xffffea0004a1d2c8 of 8 bytes by task 18600 on cpu 0:
|
|
__list_add include/linux/list.h:73 [inline]
|
|
list_add include/linux/list.h:88 [inline]
|
|
lruvec_add_folio include/linux/mm_inline.h:105 [inline]
|
|
lru_add_fn+0x440/0x520 mm/swap.c:228
|
|
folio_batch_move_lru+0x1e1/0x2a0 mm/swap.c:246
|
|
folio_batch_add_and_move mm/swap.c:263 [inline]
|
|
folio_add_lru+0xf1/0x140 mm/swap.c:490
|
|
filemap_add_folio+0xf8/0x150 mm/filemap.c:948
|
|
__filemap_get_folio+0x510/0x6d0 mm/filemap.c:1981
|
|
pagecache_get_page+0x26/0x190 mm/folio-compat.c:104
|
|
grab_cache_page_write_begin+0x2a/0x30 mm/folio-compat.c:116
|
|
ext4_da_write_begin+0x2dd/0x5f0 fs/ext4/inode.c:2988
|
|
generic_perform_write+0x1d4/0x3f0 mm/filemap.c:3738
|
|
ext4_buffered_write_iter+0x235/0x3e0 fs/ext4/file.c:270
|
|
ext4_file_write_iter+0x2e3/0x1210
|
|
call_write_iter include/linux/fs.h:2187 [inline]
|
|
new_sync_write fs/read_write.c:491 [inline]
|
|
vfs_write+0x468/0x760 fs/read_write.c:578
|
|
ksys_write+0xe8/0x1a0 fs/read_write.c:631
|
|
__do_sys_write fs/read_write.c:643 [inline]
|
|
__se_sys_write fs/read_write.c:640 [inline]
|
|
__x64_sys_write+0x3e/0x50 fs/read_write.c:640
|
|
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
|
|
do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80
|
|
entry_SYSCALL_64_after_hwframe+0x63/0xcd
|
|
|
|
read to 0xffffea0004a1d2c8 of 8 bytes by task 18611 on cpu 1:
|
|
page_is_pfmemalloc include/linux/mm.h:1740 [inline]
|
|
__skb_fill_page_desc include/linux/skbuff.h:2422 [inline]
|
|
skb_fill_page_desc include/linux/skbuff.h:2443 [inline]
|
|
tcp_build_frag+0x613/0xb20 net/ipv4/tcp.c:1018
|
|
do_tcp_sendpages+0x3e8/0xaf0 net/ipv4/tcp.c:1075
|
|
tcp_sendpage_locked net/ipv4/tcp.c:1140 [inline]
|
|
tcp_sendpage+0x89/0xb0 net/ipv4/tcp.c:1150
|
|
inet_sendpage+0x7f/0xc0 net/ipv4/af_inet.c:833
|
|
kernel_sendpage+0x184/0x300 net/socket.c:3561
|
|
sock_sendpage+0x5a/0x70 net/socket.c:1054
|
|
pipe_to_sendpage+0x128/0x160 fs/splice.c:361
|
|
splice_from_pipe_feed fs/splice.c:415 [inline]
|
|
__splice_from_pipe+0x222/0x4d0 fs/splice.c:559
|
|
splice_from_pipe fs/splice.c:594 [inline]
|
|
generic_splice_sendpage+0x89/0xc0 fs/splice.c:743
|
|
do_splice_from fs/splice.c:764 [inline]
|
|
direct_splice_actor+0x80/0xa0 fs/splice.c:931
|
|
splice_direct_to_actor+0x305/0x620 fs/splice.c:886
|
|
do_splice_direct+0xfb/0x180 fs/splice.c:974
|
|
do_sendfile+0x3bf/0x910 fs/read_write.c:1249
|
|
__do_sys_sendfile64 fs/read_write.c:1317 [inline]
|
|
__se_sys_sendfile64 fs/read_write.c:1303 [inline]
|
|
__x64_sys_sendfile64+0x10c/0x150 fs/read_write.c:1303
|
|
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
|
|
do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80
|
|
entry_SYSCALL_64_after_hwframe+0x63/0xcd
|
|
|
|
value changed: 0x0000000000000000 -> 0xffffea0004a1d288
|
|
|
|
Reported by Kernel Concurrency Sanitizer on:
|
|
CPU: 1 PID: 18611 Comm: syz-executor.4 Not tainted 6.0.0-rc2-syzkaller-00248-ge022620b5d05-dirty #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022(CVE-2022-48689)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
io_uring/af_unix: disable sending io_uring over sockets
|
|
|
|
File reference cycles have caused lots of problems for io_uring
|
|
in the past, and it still doesn't work exactly right and races with
|
|
unix_stream_read_generic(). The safest fix would be to completely
|
|
disallow sending io_uring files via sockets via SCM_RIGHT, so there
|
|
are no possible cycles invloving registered files and thus rendering
|
|
SCM accounting on the io_uring side unnecessary.(CVE-2023-52654)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
crypto: s390/aes - Fix buffer overread in CTR mode
|
|
|
|
When processing the last block, the s390 ctr code will always read
|
|
a whole block, even if there isn't a whole block of data left. Fix
|
|
this by using the actual length left and copy it into a buffer first
|
|
for processing.(CVE-2023-52669)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
riscv: Check if the code to patch lies in the exit section
|
|
|
|
Otherwise we fall through to vmalloc_to_page() which panics since the
|
|
address does not lie in the vmalloc region.(CVE-2023-52677)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
powerpc/powernv: Add a null pointer check in opal_powercap_init()
|
|
|
|
kasprintf() returns a pointer to dynamically allocated memory
|
|
which can be NULL upon failure.(CVE-2023-52696)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
sysv: don't call sb_bread() with pointers_lock held
|
|
|
|
syzbot is reporting sleep in atomic context in SysV filesystem [1], for
|
|
sb_bread() is called with rw_spinlock held.
|
|
|
|
A "write_lock(&pointers_lock) => read_lock(&pointers_lock) deadlock" bug
|
|
and a "sb_bread() with write_lock(&pointers_lock)" bug were introduced by
|
|
"Replace BKL for chain locking with sysvfs-private rwlock" in Linux 2.5.12.
|
|
|
|
Then, "[PATCH] err1-40: sysvfs locking fix" in Linux 2.6.8 fixed the
|
|
former bug by moving pointers_lock lock to the callers, but instead
|
|
introduced a "sb_bread() with read_lock(&pointers_lock)" bug (which made
|
|
this problem easier to hit).
|
|
|
|
Al Viro suggested that why not to do like get_branch()/get_block()/
|
|
find_shared() in Minix filesystem does. And doing like that is almost a
|
|
revert of "[PATCH] err1-40: sysvfs locking fix" except that get_branch()
|
|
from with find_shared() is called without write_lock(&pointers_lock).(CVE-2023-52699)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
arm64: Restrict CPU_BIG_ENDIAN to GNU as or LLVM IAS 15.x or newer
|
|
|
|
Prior to LLVM 15.0.0, LLVM's integrated assembler would incorrectly
|
|
byte-swap NOP when compiling for big-endian, and the resulting series of
|
|
bytes happened to match the encoding of FNMADD S21, S30, S0, S0.
|
|
|
|
This went unnoticed until commit:
|
|
|
|
34f66c4c4d5518c1 ("arm64: Use a positive cpucap for FP/SIMD")
|
|
|
|
Prior to that commit, the kernel would always enable the use of FPSIMD
|
|
early in boot when __cpu_setup() initialized CPACR_EL1, and so usage of
|
|
FNMADD within the kernel was not detected, but could result in the
|
|
corruption of user or kernel FPSIMD state.
|
|
|
|
After that commit, the instructions happen to trap during boot prior to
|
|
FPSIMD being detected and enabled, e.g.
|
|
|
|
| Unhandled 64-bit el1h sync exception on CPU0, ESR 0x000000001fe00000 -- ASIMD
|
|
| CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1
|
|
| Hardware name: linux,dummy-virt (DT)
|
|
| pstate: 400000c9 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
|
|
| pc : __pi_strcmp+0x1c/0x150
|
|
| lr : populate_properties+0xe4/0x254
|
|
| sp : ffffd014173d3ad0
|
|
| x29: ffffd014173d3af0 x28: fffffbfffddffcb8 x27: 0000000000000000
|
|
| x26: 0000000000000058 x25: fffffbfffddfe054 x24: 0000000000000008
|
|
| x23: fffffbfffddfe000 x22: fffffbfffddfe000 x21: fffffbfffddfe044
|
|
| x20: ffffd014173d3b70 x19: 0000000000000001 x18: 0000000000000005
|
|
| x17: 0000000000000010 x16: 0000000000000000 x15: 00000000413e7000
|
|
| x14: 0000000000000000 x13: 0000000000001bcc x12: 0000000000000000
|
|
| x11: 00000000d00dfeed x10: ffffd414193f2cd0 x9 : 0000000000000000
|
|
| x8 : 0101010101010101 x7 : ffffffffffffffc0 x6 : 0000000000000000
|
|
| x5 : 0000000000000000 x4 : 0101010101010101 x3 : 000000000000002a
|
|
| x2 : 0000000000000001 x1 : ffffd014171f2988 x0 : fffffbfffddffcb8
|
|
| Kernel panic - not syncing: Unhandled exception
|
|
| CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1
|
|
| Hardware name: linux,dummy-virt (DT)
|
|
| Call trace:
|
|
| dump_backtrace+0xec/0x108
|
|
| show_stack+0x18/0x2c
|
|
| dump_stack_lvl+0x50/0x68
|
|
| dump_stack+0x18/0x24
|
|
| panic+0x13c/0x340
|
|
| el1t_64_irq_handler+0x0/0x1c
|
|
| el1_abort+0x0/0x5c
|
|
| el1h_64_sync+0x64/0x68
|
|
| __pi_strcmp+0x1c/0x150
|
|
| unflatten_dt_nodes+0x1e8/0x2d8
|
|
| __unflatten_device_tree+0x5c/0x15c
|
|
| unflatten_device_tree+0x38/0x50
|
|
| setup_arch+0x164/0x1e0
|
|
| start_kernel+0x64/0x38c
|
|
| __primary_switched+0xbc/0xc4
|
|
|
|
Restrict CONFIG_CPU_BIG_ENDIAN to a known good assembler, which is
|
|
either GNU as or LLVM's IAS 15.0.0 and newer, which contains the linked
|
|
commit.(CVE-2023-52750)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
smb: client: fix use-after-free bug in cifs_debug_data_proc_show()
|
|
|
|
Skip SMB sessions that are being teared down
|
|
(e.g. @ses->ses_status == SES_EXITING) in cifs_debug_data_proc_show()
|
|
to avoid use-after-free in @ses.
|
|
|
|
This fixes the following GPF when reading from /proc/fs/cifs/DebugData
|
|
while mounting and umounting
|
|
|
|
[ 816.251274] general protection fault, probably for non-canonical
|
|
address 0x6b6b6b6b6b6b6d81: 0000 [#1] PREEMPT SMP NOPTI
|
|
...
|
|
[ 816.260138] Call Trace:
|
|
[ 816.260329] <TASK>
|
|
[ 816.260499] ? die_addr+0x36/0x90
|
|
[ 816.260762] ? exc_general_protection+0x1b3/0x410
|
|
[ 816.261126] ? asm_exc_general_protection+0x26/0x30
|
|
[ 816.261502] ? cifs_debug_tcon+0xbd/0x240 [cifs]
|
|
[ 816.261878] ? cifs_debug_tcon+0xab/0x240 [cifs]
|
|
[ 816.262249] cifs_debug_data_proc_show+0x516/0xdb0 [cifs]
|
|
[ 816.262689] ? seq_read_iter+0x379/0x470
|
|
[ 816.262995] seq_read_iter+0x118/0x470
|
|
[ 816.263291] proc_reg_read_iter+0x53/0x90
|
|
[ 816.263596] ? srso_alias_return_thunk+0x5/0x7f
|
|
[ 816.263945] vfs_read+0x201/0x350
|
|
[ 816.264211] ksys_read+0x75/0x100
|
|
[ 816.264472] do_syscall_64+0x3f/0x90
|
|
[ 816.264750] entry_SYSCALL_64_after_hwframe+0x6e/0xd8
|
|
[ 816.265135] RIP: 0033:0x7fd5e669d381(CVE-2023-52752)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/amd/display: Avoid NULL dereference of timing generator
|
|
|
|
[Why & How]
|
|
Check whether assigned timing generator is NULL or not before
|
|
accessing its funcs to prevent NULL dereference.(CVE-2023-52753)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
pwm: Fix double shift bug
|
|
|
|
These enums are passed to set/test_bit(). The set/test_bit() functions
|
|
take a bit number instead of a shifted value. Passing a shifted value
|
|
is a double shift bug like doing BIT(BIT(1)). The double shift bug
|
|
doesn't cause a problem here because we are only checking 0 and 1 but
|
|
if the value was 5 or above then it can lead to a buffer overflow.(CVE-2023-52756)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
gfs2: ignore negated quota changes
|
|
|
|
When lots of quota changes are made, there may be cases in which an
|
|
inode's quota information is increased and then decreased, such as when
|
|
blocks are added to a file, then deleted from it. If the timing is
|
|
right, function do_qc can add pending quota changes to a transaction,
|
|
then later, another call to do_qc can negate those changes, resulting
|
|
in a net gain of 0. The quota_change information is recorded in the qc
|
|
buffer (and qd element of the inode as well). The buffer is added to the
|
|
transaction by the first call to do_qc, but a subsequent call changes
|
|
the value from non-zero back to zero. At that point it's too late to
|
|
remove the buffer_head from the transaction. Later, when the quota sync
|
|
code is called, the zero-change qd element is discovered and flagged as
|
|
an assert warning. If the fs is mounted with errors=panic, the kernel
|
|
will panic.
|
|
|
|
This is usually seen when files are truncated and the quota changes are
|
|
negated by punch_hole/truncate which uses gfs2_quota_hold and
|
|
gfs2_quota_unhold rather than block allocations that use gfs2_quota_lock
|
|
and gfs2_quota_unlock which automatically do quota sync.
|
|
|
|
This patch solves the problem by adding a check to qd_check_sync such
|
|
that net-zero quota changes already added to the transaction are no
|
|
longer deemed necessary to be synced, and skipped.
|
|
|
|
In this case references are taken for the qd and the slot from do_qc
|
|
so those need to be put. The normal sequence of events for a normal
|
|
non-zero quota change is as follows:
|
|
|
|
gfs2_quota_change
|
|
do_qc
|
|
qd_hold
|
|
slot_hold
|
|
|
|
Later, when the changes are to be synced:
|
|
|
|
gfs2_quota_sync
|
|
qd_fish
|
|
qd_check_sync
|
|
gets qd ref via lockref_get_not_dead
|
|
do_sync
|
|
do_qc(QC_SYNC)
|
|
qd_put
|
|
lockref_put_or_lock
|
|
qd_unlock
|
|
qd_put
|
|
lockref_put_or_lock
|
|
|
|
In the net-zero change case, we add a check to qd_check_sync so it puts
|
|
the qd and slot references acquired in gfs2_quota_change and skip the
|
|
unneeded sync.(CVE-2023-52759)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
s390/dasd: protect device queue against concurrent access
|
|
|
|
In dasd_profile_start() the amount of requests on the device queue are
|
|
counted. The access to the device queue is unprotected against
|
|
concurrent access. With a lot of parallel I/O, especially with alias
|
|
devices enabled, the device queue can change while dasd_profile_start()
|
|
is accessing the queue. In the worst case this leads to a kernel panic
|
|
due to incorrect pointer accesses.
|
|
|
|
Fix this by taking the device lock before accessing the queue and
|
|
counting the requests. Additionally the check for a valid profile data
|
|
pointer can be done earlier to avoid unnecessary locking in a hot path.(CVE-2023-52774)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
tty: vcc: Add check for kstrdup() in vcc_probe()
|
|
|
|
Add check for the return value of kstrdup() and return the error, if it
|
|
fails in order to avoid NULL pointer dereference.(CVE-2023-52789)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
vhost-vdpa: fix use after free in vhost_vdpa_probe()
|
|
|
|
The put_device() calls vhost_vdpa_release_dev() which calls
|
|
ida_simple_remove() and frees "v". So this call to
|
|
ida_simple_remove() is a use after free and a double free.(CVE-2023-52795)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ipvlan: add ipvlan_route_v6_outbound() helper
|
|
|
|
Inspired by syzbot reports using a stack of multiple ipvlan devices.
|
|
|
|
Reduce stack size needed in ipvlan_process_v6_outbound() by moving
|
|
the flowi6 struct used for the route lookup in an non inlined
|
|
helper. ipvlan_route_v6_outbound() needs 120 bytes on the stack,
|
|
immediately reclaimed.
|
|
|
|
Also make sure ipvlan_process_v4_outbound() is not inlined.
|
|
|
|
We might also have to lower MAX_NEST_DEV, because only syzbot uses
|
|
setups with more than four stacked devices.
|
|
|
|
BUG: TASK stack guard page was hit at ffffc9000e803ff8 (stack is ffffc9000e804000..ffffc9000e808000)
|
|
stack guard page: 0000 [#1] SMP KASAN
|
|
CPU: 0 PID: 13442 Comm: syz-executor.4 Not tainted 6.1.52-syzkaller #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023
|
|
RIP: 0010:kasan_check_range+0x4/0x2a0 mm/kasan/generic.c:188
|
|
Code: 48 01 c6 48 89 c7 e8 db 4e c1 03 31 c0 5d c3 cc 0f 0b eb 02 0f 0b b8 ea ff ff ff 5d c3 cc 00 00 cc cc 00 00 cc cc 55 48 89 e5 <41> 57 41 56 41 55 41 54 53 b0 01 48 85 f6 0f 84 a4 01 00 00 48 89
|
|
RSP: 0018:ffffc9000e804000 EFLAGS: 00010246
|
|
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817e5bf2
|
|
RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffff887c6568
|
|
RBP: ffffc9000e804000 R08: 0000000000000000 R09: 0000000000000000
|
|
R10: 0000000000000000 R11: dffffc0000000001 R12: 1ffff92001d0080c
|
|
R13: dffffc0000000000 R14: ffffffff87e6b100 R15: 0000000000000000
|
|
FS: 00007fd0c55826c0(0000) GS:ffff8881f6800000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: ffffc9000e803ff8 CR3: 0000000170ef7000 CR4: 00000000003506f0
|
|
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
Call Trace:
|
|
<#DF>
|
|
</#DF>
|
|
<TASK>
|
|
[<ffffffff81f281d1>] __kasan_check_read+0x11/0x20 mm/kasan/shadow.c:31
|
|
[<ffffffff817e5bf2>] instrument_atomic_read include/linux/instrumented.h:72 [inline]
|
|
[<ffffffff817e5bf2>] _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]
|
|
[<ffffffff817e5bf2>] cpumask_test_cpu include/linux/cpumask.h:506 [inline]
|
|
[<ffffffff817e5bf2>] cpu_online include/linux/cpumask.h:1092 [inline]
|
|
[<ffffffff817e5bf2>] trace_lock_acquire include/trace/events/lock.h:24 [inline]
|
|
[<ffffffff817e5bf2>] lock_acquire+0xe2/0x590 kernel/locking/lockdep.c:5632
|
|
[<ffffffff8563221e>] rcu_lock_acquire+0x2e/0x40 include/linux/rcupdate.h:306
|
|
[<ffffffff8561464d>] rcu_read_lock include/linux/rcupdate.h:747 [inline]
|
|
[<ffffffff8561464d>] ip6_pol_route+0x15d/0x1440 net/ipv6/route.c:2221
|
|
[<ffffffff85618120>] ip6_pol_route_output+0x50/0x80 net/ipv6/route.c:2606
|
|
[<ffffffff856f65b5>] pol_lookup_func include/net/ip6_fib.h:584 [inline]
|
|
[<ffffffff856f65b5>] fib6_rule_lookup+0x265/0x620 net/ipv6/fib6_rules.c:116
|
|
[<ffffffff85618009>] ip6_route_output_flags_noref+0x2d9/0x3a0 net/ipv6/route.c:2638
|
|
[<ffffffff8561821a>] ip6_route_output_flags+0xca/0x340 net/ipv6/route.c:2651
|
|
[<ffffffff838bd5a3>] ip6_route_output include/net/ip6_route.h:100 [inline]
|
|
[<ffffffff838bd5a3>] ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:473 [inline]
|
|
[<ffffffff838bd5a3>] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:529 [inline]
|
|
[<ffffffff838bd5a3>] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline]
|
|
[<ffffffff838bd5a3>] ipvlan_queue_xmit+0xc33/0x1be0 drivers/net/ipvlan/ipvlan_core.c:677
|
|
[<ffffffff838c2909>] ipvlan_start_xmit+0x49/0x100 drivers/net/ipvlan/ipvlan_main.c:229
|
|
[<ffffffff84d03900>] netdev_start_xmit include/linux/netdevice.h:4966 [inline]
|
|
[<ffffffff84d03900>] xmit_one net/core/dev.c:3644 [inline]
|
|
[<ffffffff84d03900>] dev_hard_start_xmit+0x320/0x980 net/core/dev.c:3660
|
|
[<ffffffff84d080e2>] __dev_queue_xmit+0x16b2/0x3370 net/core/dev.c:4324
|
|
[<ffffffff855ce4cd>] dev_queue_xmit include/linux/netdevice.h:3067 [inline]
|
|
[<ffffffff855ce4cd>] neigh_hh_output include/net/neighbour.h:529 [inline]
|
|
[<f
|
|
---truncated---(CVE-2023-52796)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: ath11k: fix dfs radar event locking
|
|
|
|
The ath11k active pdevs are protected by RCU but the DFS radar event
|
|
handling code calling ath11k_mac_get_ar_by_pdev_id() was not marked as a
|
|
read-side critical section.
|
|
|
|
Mark the code in question as an RCU read-side critical section to avoid
|
|
any potential use-after-free issues.
|
|
|
|
Compile tested only.(CVE-2023-52798)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
jfs: fix array-index-out-of-bounds in dbFindLeaf
|
|
|
|
Currently while searching for dmtree_t for sufficient free blocks there
|
|
is an array out of bounds while getting element in tp->dm_stree. To add
|
|
the required check for out of bound we first need to determine the type
|
|
of dmtree. Thus added an extra parameter to dbFindLeaf so that the type
|
|
of tree can be determined and the required check can be applied.(CVE-2023-52799)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: ath11k: fix htt pktlog locking
|
|
|
|
The ath11k active pdevs are protected by RCU but the htt pktlog handling
|
|
code calling ath11k_mac_get_ar_by_pdev_id() was not marked as a
|
|
read-side critical section.
|
|
|
|
Mark the code in question as an RCU read-side critical section to avoid
|
|
any potential use-after-free issues.
|
|
|
|
Compile tested only.(CVE-2023-52800)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
iio: adc: stm32-adc: harden against NULL pointer deref in stm32_adc_probe()
|
|
|
|
of_match_device() may fail and returns a NULL pointer.
|
|
|
|
In practice there is no known reasonable way to trigger this, but
|
|
in case one is added in future, harden the code by adding the check(CVE-2023-52802)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/amdgpu: Fix potential null pointer derefernce
|
|
|
|
The amdgpu_ras_get_context may return NULL if device
|
|
not support ras feature, so add check before using.(CVE-2023-52814)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/amd: Fix UBSAN array-index-out-of-bounds for Polaris and Tonga
|
|
|
|
For pptable structs that use flexible array sizes, use flexible arrays.(CVE-2023-52819)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/panel/panel-tpo-tpg110: fix a possible null pointer dereference
|
|
|
|
In tpg110_get_modes(), the return value of drm_mode_duplicate() is
|
|
assigned to mode, which will lead to a NULL pointer dereference on
|
|
failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2023-52826)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
cpu/hotplug: Don't offline the last non-isolated CPU
|
|
|
|
If a system has isolated CPUs via the "isolcpus=" command line parameter,
|
|
then an attempt to offline the last housekeeping CPU will result in a
|
|
WARN_ON() when rebuilding the scheduler domains and a subsequent panic due
|
|
to and unhandled empty CPU mas in partition_sched_domains_locked().
|
|
|
|
cpuset_hotplug_workfn()
|
|
rebuild_sched_domains_locked()
|
|
ndoms = generate_sched_domains(&doms, &attr);
|
|
cpumask_and(doms[0], top_cpuset.effective_cpus, housekeeping_cpumask(HK_FLAG_DOMAIN));
|
|
|
|
Thus results in an empty CPU mask which triggers the warning and then the
|
|
subsequent crash:
|
|
|
|
WARNING: CPU: 4 PID: 80 at kernel/sched/topology.c:2366 build_sched_domains+0x120c/0x1408
|
|
Call trace:
|
|
build_sched_domains+0x120c/0x1408
|
|
partition_sched_domains_locked+0x234/0x880
|
|
rebuild_sched_domains_locked+0x37c/0x798
|
|
rebuild_sched_domains+0x30/0x58
|
|
cpuset_hotplug_workfn+0x2a8/0x930
|
|
|
|
Unable to handle kernel paging request at virtual address fffe80027ab37080
|
|
partition_sched_domains_locked+0x318/0x880
|
|
rebuild_sched_domains_locked+0x37c/0x798
|
|
|
|
Aside of the resulting crash, it does not make any sense to offline the last
|
|
last housekeeping CPU.
|
|
|
|
Prevent this by masking out the non-housekeeping CPUs when selecting a
|
|
target CPU for initiating the CPU unplug operation via the work queue.(CVE-2023-52831)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: mac80211: don't return unset power in ieee80211_get_tx_power()
|
|
|
|
We can get a UBSAN warning if ieee80211_get_tx_power() returns the
|
|
INT_MIN value mac80211 internally uses for "unset power level".
|
|
|
|
UBSAN: signed-integer-overflow in net/wireless/nl80211.c:3816:5
|
|
-2147483648 * 100 cannot be represented in type 'int'
|
|
CPU: 0 PID: 20433 Comm: insmod Tainted: G WC OE
|
|
Call Trace:
|
|
dump_stack+0x74/0x92
|
|
ubsan_epilogue+0x9/0x50
|
|
handle_overflow+0x8d/0xd0
|
|
__ubsan_handle_mul_overflow+0xe/0x10
|
|
nl80211_send_iface+0x688/0x6b0 [cfg80211]
|
|
[...]
|
|
cfg80211_register_wdev+0x78/0xb0 [cfg80211]
|
|
cfg80211_netdev_notifier_call+0x200/0x620 [cfg80211]
|
|
[...]
|
|
ieee80211_if_add+0x60e/0x8f0 [mac80211]
|
|
ieee80211_register_hw+0xda5/0x1170 [mac80211]
|
|
|
|
In this case, simply return an error instead, to indicate
|
|
that no data is available.(CVE-2023-52832)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
locking/ww_mutex/test: Fix potential workqueue corruption
|
|
|
|
In some cases running with the test-ww_mutex code, I was seeing
|
|
odd behavior where sometimes it seemed flush_workqueue was
|
|
returning before all the work threads were finished.
|
|
|
|
Often this would cause strange crashes as the mutexes would be
|
|
freed while they were being used.
|
|
|
|
Looking at the code, there is a lifetime problem as the
|
|
controlling thread that spawns the work allocates the
|
|
"struct stress" structures that are passed to the workqueue
|
|
threads. Then when the workqueue threads are finished,
|
|
they free the stress struct that was passed to them.
|
|
|
|
Unfortunately the workqueue work_struct node is in the stress
|
|
struct. Which means the work_struct is freed before the work
|
|
thread returns and while flush_workqueue is waiting.
|
|
|
|
It seems like a better idea to have the controlling thread
|
|
both allocate and free the stress structures, so that we can
|
|
be sure we don't corrupt the workqueue by freeing the structure
|
|
prematurely.
|
|
|
|
So this patch reworks the test to do so, and with this change
|
|
I no longer see the early flush_workqueue returns.(CVE-2023-52836)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
fbdev: imsttfb: fix a resource leak in probe
|
|
|
|
I've re-written the error handling but the bug is that if init_imstt()
|
|
fails we need to call iounmap(par->cmap_regs).(CVE-2023-52838)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
platform/x86: wmi: Fix opening of char device
|
|
|
|
Since commit fa1f68db6ca7 ("drivers: misc: pass miscdevice pointer via
|
|
file private data"), the miscdevice stores a pointer to itself inside
|
|
filp->private_data, which means that private_data will not be NULL when
|
|
wmi_char_open() is called. This might cause memory corruption should
|
|
wmi_char_open() be unable to find its driver, something which can
|
|
happen when the associated WMI device is deleted in wmi_free_devices().
|
|
|
|
Fix the problem by using the miscdevice pointer to retrieve the WMI
|
|
device data associated with a char device using container_of(). This
|
|
also avoids wmi_char_open() picking a wrong WMI device bound to a
|
|
driver with the same name as the original driver.(CVE-2023-52864)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
clk: mediatek: clk-mt6797: Add check for mtk_alloc_clk_data
|
|
|
|
Add the check for the return value of mtk_alloc_clk_data() in order to
|
|
avoid NULL pointer dereference.(CVE-2023-52865)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
soc: qcom: llcc: Handle a second device without data corruption
|
|
|
|
Usually there is only one llcc device. But if there were a second, even
|
|
a failed probe call would modify the global drv_data pointer. So check
|
|
if drv_data is valid before overwriting it.(CVE-2023-52871)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
clk: mediatek: clk-mt2701: Add check for mtk_alloc_clk_data
|
|
|
|
Add the check for the return value of mtk_alloc_clk_data() in order to
|
|
avoid NULL pointer dereference.(CVE-2023-52875)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
can: dev: can_put_echo_skb(): don't crash kernel if can_priv::echo_skb is accessed out of bounds
|
|
|
|
If the "struct can_priv::echoo_skb" is accessed out of bounds, this
|
|
would cause a kernel crash. Instead, issue a meaningful warning
|
|
message and return with an error.(CVE-2023-52878)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/amd/display: Fix memory leak in dm_sw_fini()
|
|
|
|
After destroying dmub_srv, the memory associated with it is
|
|
not freed, causing a memory leak:
|
|
|
|
unreferenced object 0xffff896302b45800 (size 1024):
|
|
comm "(udev-worker)", pid 222, jiffies 4294894636
|
|
hex dump (first 32 bytes):
|
|
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
backtrace (crc 6265fd77):
|
|
[<ffffffff993495ed>] kmalloc_trace+0x29d/0x340
|
|
[<ffffffffc0ea4a94>] dm_dmub_sw_init+0xb4/0x450 [amdgpu]
|
|
[<ffffffffc0ea4e55>] dm_sw_init+0x15/0x2b0 [amdgpu]
|
|
[<ffffffffc0ba8557>] amdgpu_device_init+0x1417/0x24e0 [amdgpu]
|
|
[<ffffffffc0bab285>] amdgpu_driver_load_kms+0x15/0x190 [amdgpu]
|
|
[<ffffffffc0ba09c7>] amdgpu_pci_probe+0x187/0x4e0 [amdgpu]
|
|
[<ffffffff9968fd1e>] local_pci_probe+0x3e/0x90
|
|
[<ffffffff996918a3>] pci_device_probe+0xc3/0x230
|
|
[<ffffffff99805872>] really_probe+0xe2/0x480
|
|
[<ffffffff99805c98>] __driver_probe_device+0x78/0x160
|
|
[<ffffffff99805daf>] driver_probe_device+0x1f/0x90
|
|
[<ffffffff9980601e>] __driver_attach+0xce/0x1c0
|
|
[<ffffffff99803170>] bus_for_each_dev+0x70/0xc0
|
|
[<ffffffff99804822>] bus_add_driver+0x112/0x210
|
|
[<ffffffff99807245>] driver_register+0x55/0x100
|
|
[<ffffffff990012d1>] do_one_initcall+0x41/0x300
|
|
|
|
Fix this by freeing dmub_srv after destroying it.(CVE-2024-26833)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
crypto: xilinx - call finalize with bh disabled
|
|
|
|
When calling crypto_finalize_request, BH should be disabled to avoid
|
|
triggering the following calltrace:
|
|
|
|
------------[ cut here ]------------
|
|
WARNING: CPU: 2 PID: 74 at crypto/crypto_engine.c:58 crypto_finalize_request+0xa0/0x118
|
|
Modules linked in: cryptodev(O)
|
|
CPU: 2 PID: 74 Comm: firmware:zynqmp Tainted: G O 6.8.0-rc1-yocto-standard #323
|
|
Hardware name: ZynqMP ZCU102 Rev1.0 (DT)
|
|
pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
|
|
pc : crypto_finalize_request+0xa0/0x118
|
|
lr : crypto_finalize_request+0x104/0x118
|
|
sp : ffffffc085353ce0
|
|
x29: ffffffc085353ce0 x28: 0000000000000000 x27: ffffff8808ea8688
|
|
x26: ffffffc081715038 x25: 0000000000000000 x24: ffffff880100db00
|
|
x23: ffffff880100da80 x22: 0000000000000000 x21: 0000000000000000
|
|
x20: ffffff8805b14000 x19: ffffff880100da80 x18: 0000000000010450
|
|
x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
|
|
x14: 0000000000000003 x13: 0000000000000000 x12: ffffff880100dad0
|
|
x11: 0000000000000000 x10: ffffffc0832dcd08 x9 : ffffffc0812416d8
|
|
x8 : 00000000000001f4 x7 : ffffffc0830d2830 x6 : 0000000000000001
|
|
x5 : ffffffc082091000 x4 : ffffffc082091658 x3 : 0000000000000000
|
|
x2 : ffffffc7f9653000 x1 : 0000000000000000 x0 : ffffff8802d20000
|
|
Call trace:
|
|
crypto_finalize_request+0xa0/0x118
|
|
crypto_finalize_aead_request+0x18/0x30
|
|
zynqmp_handle_aes_req+0xcc/0x388
|
|
crypto_pump_work+0x168/0x2d8
|
|
kthread_worker_fn+0xfc/0x3a0
|
|
kthread+0x118/0x138
|
|
ret_from_fork+0x10/0x20
|
|
irq event stamp: 40
|
|
hardirqs last enabled at (39): [<ffffffc0812416f8>] _raw_spin_unlock_irqrestore+0x70/0xb0
|
|
hardirqs last disabled at (40): [<ffffffc08122d208>] el1_dbg+0x28/0x90
|
|
softirqs last enabled at (36): [<ffffffc080017dec>] kernel_neon_begin+0x8c/0xf0
|
|
softirqs last disabled at (34): [<ffffffc080017dc0>] kernel_neon_begin+0x60/0xf0
|
|
---[ end trace 0000000000000000 ]---(CVE-2024-26877)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
USB: core: Fix deadlock in usb_deauthorize_interface()
|
|
|
|
Among the attribute file callback routines in
|
|
drivers/usb/core/sysfs.c, the interface_authorized_store() function is
|
|
the only one which acquires a device lock on an ancestor device: It
|
|
calls usb_deauthorize_interface(), which locks the interface's parent
|
|
USB device.
|
|
|
|
The will lead to deadlock if another process already owns that lock
|
|
and tries to remove the interface, whether through a configuration
|
|
change or because the device has been disconnected. As part of the
|
|
removal procedure, device_del() waits for all ongoing sysfs attribute
|
|
callbacks to complete. But usb_deauthorize_interface() can't complete
|
|
until the device lock has been released, and the lock won't be
|
|
released until the removal has finished.
|
|
|
|
The mechanism provided by sysfs to prevent this kind of deadlock is
|
|
to use the sysfs_break_active_protection() function, which tells sysfs
|
|
not to wait for the attribute callback.
|
|
|
|
Reported-and-tested by: Yue Sun <samsun1006219@gmail.com>
|
|
Reported by: xingwei lee <xrivendell7@gmail.com>(CVE-2024-26934)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netfilter: nf_tables: Fix potential data-race in __nft_expr_type_get()
|
|
|
|
nft_unregister_expr() can concurrent with __nft_expr_type_get(),
|
|
and there is not any protection when iterate over nf_tables_expressions
|
|
list in __nft_expr_type_get(). Therefore, there is potential data-race
|
|
of nf_tables_expressions list entry.
|
|
|
|
Use list_for_each_entry_rcu() to iterate over nf_tables_expressions
|
|
list in __nft_expr_type_get(), and use rcu_read_lock() in the caller
|
|
nft_expr_type_get() to protect the entire type query process.(CVE-2024-27020)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
Bluetooth: l2cap: fix null-ptr-deref in l2cap_chan_timeout
|
|
|
|
There is a race condition between l2cap_chan_timeout() and
|
|
l2cap_chan_del(). When we use l2cap_chan_del() to delete the
|
|
channel, the chan->conn will be set to null. But the conn could
|
|
be dereferenced again in the mutex_lock() of l2cap_chan_timeout().
|
|
As a result the null pointer dereference bug will happen. The
|
|
KASAN report triggered by POC is shown below:
|
|
|
|
[ 472.074580] ==================================================================
|
|
[ 472.075284] BUG: KASAN: null-ptr-deref in mutex_lock+0x68/0xc0
|
|
[ 472.075308] Write of size 8 at addr 0000000000000158 by task kworker/0:0/7
|
|
[ 472.075308]
|
|
[ 472.075308] CPU: 0 PID: 7 Comm: kworker/0:0 Not tainted 6.9.0-rc5-00356-g78c0094a146b #36
|
|
[ 472.075308] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4
|
|
[ 472.075308] Workqueue: events l2cap_chan_timeout
|
|
[ 472.075308] Call Trace:
|
|
[ 472.075308] <TASK>
|
|
[ 472.075308] dump_stack_lvl+0x137/0x1a0
|
|
[ 472.075308] print_report+0x101/0x250
|
|
[ 472.075308] ? __virt_addr_valid+0x77/0x160
|
|
[ 472.075308] ? mutex_lock+0x68/0xc0
|
|
[ 472.075308] kasan_report+0x139/0x170
|
|
[ 472.075308] ? mutex_lock+0x68/0xc0
|
|
[ 472.075308] kasan_check_range+0x2c3/0x2e0
|
|
[ 472.075308] mutex_lock+0x68/0xc0
|
|
[ 472.075308] l2cap_chan_timeout+0x181/0x300
|
|
[ 472.075308] process_one_work+0x5d2/0xe00
|
|
[ 472.075308] worker_thread+0xe1d/0x1660
|
|
[ 472.075308] ? pr_cont_work+0x5e0/0x5e0
|
|
[ 472.075308] kthread+0x2b7/0x350
|
|
[ 472.075308] ? pr_cont_work+0x5e0/0x5e0
|
|
[ 472.075308] ? kthread_blkcg+0xd0/0xd0
|
|
[ 472.075308] ret_from_fork+0x4d/0x80
|
|
[ 472.075308] ? kthread_blkcg+0xd0/0xd0
|
|
[ 472.075308] ret_from_fork_asm+0x11/0x20
|
|
[ 472.075308] </TASK>
|
|
[ 472.075308] ==================================================================
|
|
[ 472.094860] Disabling lock debugging due to kernel taint
|
|
[ 472.096136] BUG: kernel NULL pointer dereference, address: 0000000000000158
|
|
[ 472.096136] #PF: supervisor write access in kernel mode
|
|
[ 472.096136] #PF: error_code(0x0002) - not-present page
|
|
[ 472.096136] PGD 0 P4D 0
|
|
[ 472.096136] Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI
|
|
[ 472.096136] CPU: 0 PID: 7 Comm: kworker/0:0 Tainted: G B 6.9.0-rc5-00356-g78c0094a146b #36
|
|
[ 472.096136] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4
|
|
[ 472.096136] Workqueue: events l2cap_chan_timeout
|
|
[ 472.096136] RIP: 0010:mutex_lock+0x88/0xc0
|
|
[ 472.096136] Code: be 08 00 00 00 e8 f8 23 1f fd 4c 89 f7 be 08 00 00 00 e8 eb 23 1f fd 42 80 3c 23 00 74 08 48 88
|
|
[ 472.096136] RSP: 0018:ffff88800744fc78 EFLAGS: 00000246
|
|
[ 472.096136] RAX: 0000000000000000 RBX: 1ffff11000e89f8f RCX: ffffffff8457c865
|
|
[ 472.096136] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffff88800744fc78
|
|
[ 472.096136] RBP: 0000000000000158 R08: ffff88800744fc7f R09: 1ffff11000e89f8f
|
|
[ 472.096136] R10: dffffc0000000000 R11: ffffed1000e89f90 R12: dffffc0000000000
|
|
[ 472.096136] R13: 0000000000000158 R14: ffff88800744fc78 R15: ffff888007405a00
|
|
[ 472.096136] FS: 0000000000000000(0000) GS:ffff88806d200000(0000) knlGS:0000000000000000
|
|
[ 472.096136] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ 472.096136] CR2: 0000000000000158 CR3: 000000000da32000 CR4: 00000000000006f0
|
|
[ 472.096136] Call Trace:
|
|
[ 472.096136] <TASK>
|
|
[ 472.096136] ? __die_body+0x8d/0xe0
|
|
[ 472.096136] ? page_fault_oops+0x6b8/0x9a0
|
|
[ 472.096136] ? kernelmode_fixup_or_oops+0x20c/0x2a0
|
|
[ 472.096136] ? do_user_addr_fault+0x1027/0x1340
|
|
[ 472.096136] ? _printk+0x7a/0xa0
|
|
[ 472.096136] ? mutex_lock+0x68/0xc0
|
|
[ 472.096136] ? add_taint+0x42/0xd0
|
|
[ 472.096136] ? exc_page_fault+0x6a/0x1b0
|
|
[ 472.096136] ? asm_exc_page_fault+0x26/0x30
|
|
[ 472.096136] ? mutex_lock+0x75/0xc0
|
|
[ 472.096136] ? mutex_lock+0x88/0xc0
|
|
[ 472.096136] ? mutex_lock+0x75/0xc0
|
|
[ 472.096136] l2cap_chan_timeo
|
|
---truncated---(CVE-2024-27399)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
firewire: nosy: ensure user_length is taken into account when fetching packet contents
|
|
|
|
Ensure that packet_buffer_get respects the user_length provided. If
|
|
the length of the head packet exceeds the user_length, packet_buffer_get
|
|
will now return 0 to signify to the user that no data were read
|
|
and a larger buffer size is required. Helps prevent user space overflows.(CVE-2024-27401)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
efi/capsule-loader: fix incorrect allocation size
|
|
|
|
gcc-14 notices that the allocation with sizeof(void) on 32-bit architectures
|
|
is not enough for a 64-bit phys_addr_t:
|
|
|
|
drivers/firmware/efi/capsule-loader.c: In function 'efi_capsule_open':
|
|
drivers/firmware/efi/capsule-loader.c:295:24: error: allocation of insufficient size '4' for type 'phys_addr_t' {aka 'long long unsigned int'} with size '8' [-Werror=alloc-size]
|
|
295 | cap_info->phys = kzalloc(sizeof(void *), GFP_KERNEL);
|
|
| ^
|
|
|
|
Use the correct type instead here.(CVE-2024-27413)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netfilter: bridge: confirm multicast packets before passing them up the stack
|
|
|
|
conntrack nf_confirm logic cannot handle cloned skbs referencing
|
|
the same nf_conn entry, which will happen for multicast (broadcast)
|
|
frames on bridges.
|
|
|
|
Example:
|
|
macvlan0
|
|
|
|
|
br0
|
|
/ \
|
|
ethX ethY
|
|
|
|
ethX (or Y) receives a L2 multicast or broadcast packet containing
|
|
an IP packet, flow is not yet in conntrack table.
|
|
|
|
1. skb passes through bridge and fake-ip (br_netfilter)Prerouting.
|
|
-> skb->_nfct now references a unconfirmed entry
|
|
2. skb is broad/mcast packet. bridge now passes clones out on each bridge
|
|
interface.
|
|
3. skb gets passed up the stack.
|
|
4. In macvlan case, macvlan driver retains clone(s) of the mcast skb
|
|
and schedules a work queue to send them out on the lower devices.
|
|
|
|
The clone skb->_nfct is not a copy, it is the same entry as the
|
|
original skb. The macvlan rx handler then returns RX_HANDLER_PASS.
|
|
5. Normal conntrack hooks (in NF_INET_LOCAL_IN) confirm the orig skb.
|
|
|
|
The Macvlan broadcast worker and normal confirm path will race.
|
|
|
|
This race will not happen if step 2 already confirmed a clone. In that
|
|
case later steps perform skb_clone() with skb->_nfct already confirmed (in
|
|
hash table). This works fine.
|
|
|
|
But such confirmation won't happen when eb/ip/nftables rules dropped the
|
|
packets before they reached the nf_confirm step in postrouting.
|
|
|
|
Pablo points out that nf_conntrack_bridge doesn't allow use of stateful
|
|
nat, so we can safely discard the nf_conn entry and let inet call
|
|
conntrack again.
|
|
|
|
This doesn't work for bridge netfilter: skb could have a nat
|
|
transformation. Also bridge nf prevents re-invocation of inet prerouting
|
|
via 'sabotage_in' hook.
|
|
|
|
Work around this problem by explicit confirmation of the entry at LOCAL_IN
|
|
time, before upper layer has a chance to clone the unconfirmed entry.
|
|
|
|
The downside is that this disables NAT and conntrack helpers.
|
|
|
|
Alternative fix would be to add locking to all code parts that deal with
|
|
unconfirmed packets, but even if that could be done in a sane way this
|
|
opens up other problems, for example:
|
|
|
|
-m physdev --physdev-out eth0 -j SNAT --snat-to 1.2.3.4
|
|
-m physdev --physdev-out eth1 -j SNAT --snat-to 1.2.3.5
|
|
|
|
For multicast case, only one of such conflicting mappings will be
|
|
created, conntrack only handles 1:1 NAT mappings.
|
|
|
|
Users should set create a setup that explicitly marks such traffic
|
|
NOTRACK (conntrack bypass) to avoid this, but we cannot auto-bypass
|
|
them, ruleset might have accept rules for untracked traffic already,
|
|
so user-visible behaviour would change.(CVE-2024-27415)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: mac80211: check/clear fast rx for non-4addr sta VLAN changes
|
|
|
|
When moving a station out of a VLAN and deleting the VLAN afterwards, the
|
|
fast_rx entry still holds a pointer to the VLAN's netdev, which can cause
|
|
use-after-free bugs. Fix this by immediately calling ieee80211_check_fast_rx
|
|
after the VLAN change.(CVE-2024-35789)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
md/dm-raid: don't call md_reap_sync_thread() directly
|
|
|
|
Currently md_reap_sync_thread() is called from raid_message() directly
|
|
without holding 'reconfig_mutex', this is definitely unsafe because
|
|
md_reap_sync_thread() can change many fields that is protected by
|
|
'reconfig_mutex'.
|
|
|
|
However, hold 'reconfig_mutex' here is still problematic because this
|
|
will cause deadlock, for example, commit 130443d60b1b ("md: refactor
|
|
idle/frozen_sync_thread() to fix deadlock").
|
|
|
|
Fix this problem by using stop_sync_thread() to unregister sync_thread,
|
|
like md/raid did.(CVE-2024-35808)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
usb: udc: remove warning when queue disabled ep
|
|
|
|
It is possible trigger below warning message from mass storage function,
|
|
|
|
WARNING: CPU: 6 PID: 3839 at drivers/usb/gadget/udc/core.c:294 usb_ep_queue+0x7c/0x104
|
|
pc : usb_ep_queue+0x7c/0x104
|
|
lr : fsg_main_thread+0x494/0x1b3c
|
|
|
|
Root cause is mass storage function try to queue request from main thread,
|
|
but other thread may already disable ep when function disable.
|
|
|
|
As there is no function failure in the driver, in order to avoid effort
|
|
to fix warning, change WARN_ON_ONCE() in usb_ep_queue() to pr_debug().(CVE-2024-35822)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
vt: fix unicode buffer corruption when deleting characters
|
|
|
|
This is the same issue that was fixed for the VGA text buffer in commit
|
|
39cdb68c64d8 ("vt: fix memory overlapping when deleting chars in the
|
|
buffer"). The cure is also the same i.e. replace memcpy() with memmove()
|
|
due to the overlaping buffers.(CVE-2024-35823)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
mptcp: use OPTION_MPTCP_MPJ_SYNACK in subflow_finish_connect()
|
|
|
|
subflow_finish_connect() uses four fields (backup, join_id, thmac, none)
|
|
that may contain garbage unless OPTION_MPTCP_MPJ_SYNACK has been set
|
|
in mptcp_parse_option()(CVE-2024-35840)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
mlxsw: spectrum_acl_tcam: Fix possible use-after-free during activity update
|
|
|
|
The rule activity update delayed work periodically traverses the list of
|
|
configured rules and queries their activity from the device.
|
|
|
|
As part of this task it accesses the entry pointed by 'ventry->entry',
|
|
but this entry can be changed concurrently by the rehash delayed work,
|
|
leading to a use-after-free [1].
|
|
|
|
Fix by closing the race and perform the activity query under the
|
|
'vregion->lock' mutex.
|
|
|
|
[1]
|
|
BUG: KASAN: slab-use-after-free in mlxsw_sp_acl_tcam_flower_rule_activity_get+0x121/0x140
|
|
Read of size 8 at addr ffff8881054ed808 by task kworker/0:18/181
|
|
|
|
CPU: 0 PID: 181 Comm: kworker/0:18 Not tainted 6.9.0-rc2-custom-00781-gd5ab772d32f7 #2
|
|
Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019
|
|
Workqueue: mlxsw_core mlxsw_sp_acl_rule_activity_update_work
|
|
Call Trace:
|
|
<TASK>
|
|
dump_stack_lvl+0xc6/0x120
|
|
print_report+0xce/0x670
|
|
kasan_report+0xd7/0x110
|
|
mlxsw_sp_acl_tcam_flower_rule_activity_get+0x121/0x140
|
|
mlxsw_sp_acl_rule_activity_update_work+0x219/0x400
|
|
process_one_work+0x8eb/0x19b0
|
|
worker_thread+0x6c9/0xf70
|
|
kthread+0x2c9/0x3b0
|
|
ret_from_fork+0x4d/0x80
|
|
ret_from_fork_asm+0x1a/0x30
|
|
</TASK>
|
|
|
|
Allocated by task 1039:
|
|
kasan_save_stack+0x33/0x60
|
|
kasan_save_track+0x14/0x30
|
|
__kasan_kmalloc+0x8f/0xa0
|
|
__kmalloc+0x19c/0x360
|
|
mlxsw_sp_acl_tcam_entry_create+0x7b/0x1f0
|
|
mlxsw_sp_acl_tcam_vchunk_migrate_all+0x30d/0xb50
|
|
mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300
|
|
process_one_work+0x8eb/0x19b0
|
|
worker_thread+0x6c9/0xf70
|
|
kthread+0x2c9/0x3b0
|
|
ret_from_fork+0x4d/0x80
|
|
ret_from_fork_asm+0x1a/0x30
|
|
|
|
Freed by task 1039:
|
|
kasan_save_stack+0x33/0x60
|
|
kasan_save_track+0x14/0x30
|
|
kasan_save_free_info+0x3b/0x60
|
|
poison_slab_object+0x102/0x170
|
|
__kasan_slab_free+0x14/0x30
|
|
kfree+0xc1/0x290
|
|
mlxsw_sp_acl_tcam_vchunk_migrate_all+0x3d7/0xb50
|
|
mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300
|
|
process_one_work+0x8eb/0x19b0
|
|
worker_thread+0x6c9/0xf70
|
|
kthread+0x2c9/0x3b0
|
|
ret_from_fork+0x4d/0x80
|
|
ret_from_fork_asm+0x1a/0x30(CVE-2024-35855)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
x86/mm/pat: fix VM_PAT handling in COW mappings
|
|
|
|
PAT handling won't do the right thing in COW mappings: the first PTE (or,
|
|
in fact, all PTEs) can be replaced during write faults to point at anon
|
|
folios. Reliably recovering the correct PFN and cachemode using
|
|
follow_phys() from PTEs will not work in COW mappings.
|
|
|
|
Using follow_phys(), we might just get the address+protection of the anon
|
|
folio (which is very wrong), or fail on swap/nonswap entries, failing
|
|
follow_phys() and triggering a WARN_ON_ONCE() in untrack_pfn() and
|
|
track_pfn_copy(), not properly calling free_pfn_range().
|
|
|
|
In free_pfn_range(), we either wouldn't call memtype_free() or would call
|
|
it with the wrong range, possibly leaking memory.
|
|
|
|
To fix that, let's update follow_phys() to refuse returning anon folios,
|
|
and fallback to using the stored PFN inside vma->vm_pgoff for COW mappings
|
|
if we run into that.
|
|
|
|
We will now properly handle untrack_pfn() with COW mappings, where we
|
|
don't need the cachemode. We'll have to fail fork()->track_pfn_copy() if
|
|
the first page was replaced by an anon folio, though: we'd have to store
|
|
the cachemode in the VMA to make this work, likely growing the VMA size.
|
|
|
|
For now, lets keep it simple and let track_pfn_copy() just fail in that
|
|
case: it would have failed in the past with swap/nonswap entries already,
|
|
and it would have done the wrong thing with anon folios.
|
|
|
|
Simple reproducer to trigger the WARN_ON_ONCE() in untrack_pfn():
|
|
|
|
<--- C reproducer --->
|
|
#include <stdio.h>
|
|
#include <sys/mman.h>
|
|
#include <unistd.h>
|
|
#include <liburing.h>
|
|
|
|
int main(void)
|
|
{
|
|
struct io_uring_params p = {};
|
|
int ring_fd;
|
|
size_t size;
|
|
char *map;
|
|
|
|
ring_fd = io_uring_setup(1, &p);
|
|
if (ring_fd < 0) {
|
|
perror("io_uring_setup");
|
|
return 1;
|
|
}
|
|
size = p.sq_off.array + p.sq_entries * sizeof(unsigned);
|
|
|
|
/* Map the submission queue ring MAP_PRIVATE */
|
|
map = mmap(0, size, PROT_READ | PROT_WRITE, MAP_PRIVATE,
|
|
ring_fd, IORING_OFF_SQ_RING);
|
|
if (map == MAP_FAILED) {
|
|
perror("mmap");
|
|
return 1;
|
|
}
|
|
|
|
/* We have at least one page. Let's COW it. */
|
|
*map = 0;
|
|
pause();
|
|
return 0;
|
|
}
|
|
<--- C reproducer --->
|
|
|
|
On a system with 16 GiB RAM and swap configured:
|
|
# ./iouring &
|
|
# memhog 16G
|
|
# killall iouring
|
|
[ 301.552930] ------------[ cut here ]------------
|
|
[ 301.553285] WARNING: CPU: 7 PID: 1402 at arch/x86/mm/pat/memtype.c:1060 untrack_pfn+0xf4/0x100
|
|
[ 301.553989] Modules linked in: binfmt_misc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_g
|
|
[ 301.558232] CPU: 7 PID: 1402 Comm: iouring Not tainted 6.7.5-100.fc38.x86_64 #1
|
|
[ 301.558772] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebu4
|
|
[ 301.559569] RIP: 0010:untrack_pfn+0xf4/0x100
|
|
[ 301.559893] Code: 75 c4 eb cf 48 8b 43 10 8b a8 e8 00 00 00 3b 6b 28 74 b8 48 8b 7b 30 e8 ea 1a f7 000
|
|
[ 301.561189] RSP: 0018:ffffba2c0377fab8 EFLAGS: 00010282
|
|
[ 301.561590] RAX: 00000000ffffffea RBX: ffff9208c8ce9cc0 RCX: 000000010455e047
|
|
[ 301.562105] RDX: 07fffffff0eb1e0a RSI: 0000000000000000 RDI: ffff9208c391d200
|
|
[ 301.562628] RBP: 0000000000000000 R08: ffffba2c0377fab8 R09: 0000000000000000
|
|
[ 301.563145] R10: ffff9208d2292d50 R11: 0000000000000002 R12: 00007fea890e0000
|
|
[ 301.563669] R13: 0000000000000000 R14: ffffba2c0377fc08 R15: 0000000000000000
|
|
[ 301.564186] FS: 0000000000000000(0000) GS:ffff920c2fbc0000(0000) knlGS:0000000000000000
|
|
[ 301.564773] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ 301.565197] CR2: 00007fea88ee8a20 CR3: 00000001033a8000 CR4: 0000000000750ef0
|
|
[ 301.565725] PKRU: 55555554
|
|
[ 301.565944] Call Trace:
|
|
[ 301.566148] <TASK>
|
|
[ 301.566325] ? untrack_pfn+0xf4/0x100
|
|
[ 301.566618] ? __warn+0x81/0x130
|
|
[ 301.566876] ? untrack_pfn+0xf4/0x100
|
|
[ 3
|
|
---truncated---(CVE-2024-35877)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netfilter: nf_tables: reject new basechain after table flag update
|
|
|
|
When dormant flag is toggled, hooks are disabled in the commit phase by
|
|
iterating over current chains in table (existing and new).
|
|
|
|
The following configuration allows for an inconsistent state:
|
|
|
|
add table x
|
|
add chain x y { type filter hook input priority 0; }
|
|
add table x { flags dormant; }
|
|
add chain x w { type filter hook input priority 1; }
|
|
|
|
which triggers the following warning when trying to unregister chain w
|
|
which is already unregistered.
|
|
|
|
[ 127.322252] WARNING: CPU: 7 PID: 1211 at net/netfilter/core.c:50 1 __nf_unregister_net_hook+0x21a/0x260
|
|
[...]
|
|
[ 127.322519] Call Trace:
|
|
[ 127.322521] <TASK>
|
|
[ 127.322524] ? __warn+0x9f/0x1a0
|
|
[ 127.322531] ? __nf_unregister_net_hook+0x21a/0x260
|
|
[ 127.322537] ? report_bug+0x1b1/0x1e0
|
|
[ 127.322545] ? handle_bug+0x3c/0x70
|
|
[ 127.322552] ? exc_invalid_op+0x17/0x40
|
|
[ 127.322556] ? asm_exc_invalid_op+0x1a/0x20
|
|
[ 127.322563] ? kasan_save_free_info+0x3b/0x60
|
|
[ 127.322570] ? __nf_unregister_net_hook+0x6a/0x260
|
|
[ 127.322577] ? __nf_unregister_net_hook+0x21a/0x260
|
|
[ 127.322583] ? __nf_unregister_net_hook+0x6a/0x260
|
|
[ 127.322590] ? __nf_tables_unregister_hook+0x8a/0xe0 [nf_tables]
|
|
[ 127.322655] nft_table_disable+0x75/0xf0 [nf_tables]
|
|
[ 127.322717] nf_tables_commit+0x2571/0x2620 [nf_tables](CVE-2024-35900)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
selinux: avoid dereference of garbage after mount failure
|
|
|
|
In case kern_mount() fails and returns an error pointer return in the
|
|
error branch instead of continuing and dereferencing the error pointer.
|
|
|
|
While on it drop the never read static variable selinuxfs_mount.(CVE-2024-35904)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
block: prevent division by zero in blk_rq_stat_sum()
|
|
|
|
The expression dst->nr_samples + src->nr_samples may
|
|
have zero value on overflow. It is necessary to add
|
|
a check to avoid division by zero.
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with Svace.(CVE-2024-35925)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
dma-direct: Leak pages on dma_set_decrypted() failure
|
|
|
|
On TDX it is possible for the untrusted host to cause
|
|
set_memory_encrypted() or set_memory_decrypted() to fail such that an
|
|
error is returned and the resulting memory is shared. Callers need to
|
|
take care to handle these errors to avoid returning decrypted (shared)
|
|
memory to the page allocator, which could lead to functional or security
|
|
issues.
|
|
|
|
DMA could free decrypted/shared pages if dma_set_decrypted() fails. This
|
|
should be a rare case. Just leak the pages in this case instead of
|
|
freeing them.(CVE-2024-35939)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/client: Fully protect modes[] with dev->mode_config.mutex
|
|
|
|
The modes[] array contains pointers to modes on the connectors'
|
|
mode lists, which are protected by dev->mode_config.mutex.
|
|
Thus we need to extend modes[] the same protection or by the
|
|
time we use it the elements may already be pointing to
|
|
freed/reused memory.(CVE-2024-35950)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
btrfs: qgroup: fix qgroup prealloc rsv leak in subvolume operations
|
|
|
|
Create subvolume, create snapshot and delete subvolume all use
|
|
btrfs_subvolume_reserve_metadata() to reserve metadata for the changes
|
|
done to the parent subvolume's fs tree, which cannot be mediated in the
|
|
normal way via start_transaction. When quota groups (squota or qgroups)
|
|
are enabled, this reserves qgroup metadata of type PREALLOC. Once the
|
|
operation is associated to a transaction, we convert PREALLOC to
|
|
PERTRANS, which gets cleared in bulk at the end of the transaction.
|
|
|
|
However, the error paths of these three operations were not implementing
|
|
this lifecycle correctly. They unconditionally converted the PREALLOC to
|
|
PERTRANS in a generic cleanup step regardless of errors or whether the
|
|
operation was fully associated to a transaction or not. This resulted in
|
|
error paths occasionally converting this rsv to PERTRANS without calling
|
|
record_root_in_trans successfully, which meant that unless that root got
|
|
recorded in the transaction by some other thread, the end of the
|
|
transaction would not free that root's PERTRANS, leaking it. Ultimately,
|
|
this resulted in hitting a WARN in CONFIG_BTRFS_DEBUG builds at unmount
|
|
for the leaked reservation.
|
|
|
|
The fix is to ensure that every qgroup PREALLOC reservation observes the
|
|
following properties:
|
|
|
|
1. any failure before record_root_in_trans is called successfully
|
|
results in freeing the PREALLOC reservation.
|
|
2. after record_root_in_trans, we convert to PERTRANS, and now the
|
|
transaction owns freeing the reservation.
|
|
|
|
This patch enforces those properties on the three operations. Without
|
|
it, generic/269 with squotas enabled at mkfs time would fail in ~5-10
|
|
runs on my system. With this patch, it ran successfully 1000 times in a
|
|
row.(CVE-2024-35956)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: ena: Fix incorrect descriptor free behavior
|
|
|
|
ENA has two types of TX queues:
|
|
- queues which only process TX packets arriving from the network stack
|
|
- queues which only process TX packets forwarded to it by XDP_REDIRECT
|
|
or XDP_TX instructions
|
|
|
|
The ena_free_tx_bufs() cycles through all descriptors in a TX queue
|
|
and unmaps + frees every descriptor that hasn't been acknowledged yet
|
|
by the device (uncompleted TX transactions).
|
|
The function assumes that the processed TX queue is necessarily from
|
|
the first category listed above and ends up using napi_consume_skb()
|
|
for descriptors belonging to an XDP specific queue.
|
|
|
|
This patch solves a bug in which, in case of a VF reset, the
|
|
descriptors aren't freed correctly, leading to crashes.(CVE-2024-35958)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/mlx5: Properly link new fs rules into the tree
|
|
|
|
Previously, add_rule_fg would only add newly created rules from the
|
|
handle into the tree when they had a refcount of 1. On the other hand,
|
|
create_flow_handle tries hard to find and reference already existing
|
|
identical rules instead of creating new ones.
|
|
|
|
These two behaviors can result in a situation where create_flow_handle
|
|
1) creates a new rule and references it, then
|
|
2) in a subsequent step during the same handle creation references it
|
|
again,
|
|
resulting in a rule with a refcount of 2 that is not linked into the
|
|
tree, will have a NULL parent and root and will result in a crash when
|
|
the flow group is deleted because del_sw_hw_rule, invoked on rule
|
|
deletion, assumes node->parent is != NULL.
|
|
|
|
This happened in the wild, due to another bug related to incorrect
|
|
handling of duplicate pkt_reformat ids, which lead to the code in
|
|
create_flow_handle incorrectly referencing a just-added rule in the same
|
|
flow handle, resulting in the problem described above. Full details are
|
|
at [1].
|
|
|
|
This patch changes add_rule_fg to add new rules without parents into
|
|
the tree, properly initializing them and avoiding the crash. This makes
|
|
it more consistent with how rules are added to an FTE in
|
|
create_flow_handle.(CVE-2024-35960)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
Bluetooth: Fix memory leak in hci_req_sync_complete()
|
|
|
|
In 'hci_req_sync_complete()', always free the previous sync
|
|
request state before assigning reference to a new one.(CVE-2024-35978)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
dmaengine: idxd: Fix oops during rmmod on single-CPU platforms
|
|
|
|
During the removal of the idxd driver, registered offline callback is
|
|
invoked as part of the clean up process. However, on systems with only
|
|
one CPU online, no valid target is available to migrate the
|
|
perf context, resulting in a kernel oops:
|
|
|
|
BUG: unable to handle page fault for address: 000000000002a2b8
|
|
#PF: supervisor write access in kernel mode
|
|
#PF: error_code(0x0002) - not-present page
|
|
PGD 1470e1067 P4D 0
|
|
Oops: 0002 [#1] PREEMPT SMP NOPTI
|
|
CPU: 0 PID: 20 Comm: cpuhp/0 Not tainted 6.8.0-rc6-dsa+ #57
|
|
Hardware name: Intel Corporation AvenueCity/AvenueCity, BIOS BHSDCRB1.86B.2492.D03.2307181620 07/18/2023
|
|
RIP: 0010:mutex_lock+0x2e/0x50
|
|
...
|
|
Call Trace:
|
|
<TASK>
|
|
__die+0x24/0x70
|
|
page_fault_oops+0x82/0x160
|
|
do_user_addr_fault+0x65/0x6b0
|
|
__pfx___rdmsr_safe_on_cpu+0x10/0x10
|
|
exc_page_fault+0x7d/0x170
|
|
asm_exc_page_fault+0x26/0x30
|
|
mutex_lock+0x2e/0x50
|
|
mutex_lock+0x1e/0x50
|
|
perf_pmu_migrate_context+0x87/0x1f0
|
|
perf_event_cpu_offline+0x76/0x90 [idxd]
|
|
cpuhp_invoke_callback+0xa2/0x4f0
|
|
__pfx_perf_event_cpu_offline+0x10/0x10 [idxd]
|
|
cpuhp_thread_fun+0x98/0x150
|
|
smpboot_thread_fn+0x27/0x260
|
|
smpboot_thread_fn+0x1af/0x260
|
|
__pfx_smpboot_thread_fn+0x10/0x10
|
|
kthread+0x103/0x140
|
|
__pfx_kthread+0x10/0x10
|
|
ret_from_fork+0x31/0x50
|
|
__pfx_kthread+0x10/0x10
|
|
ret_from_fork_asm+0x1b/0x30
|
|
<TASK>
|
|
|
|
Fix the issue by preventing the migration of the perf context to an
|
|
invalid target.(CVE-2024-35989)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
mm/hugetlb: fix missing hugetlb_lock for resv uncharge
|
|
|
|
There is a recent report on UFFDIO_COPY over hugetlb:
|
|
|
|
https://lore.kernel.org/all/000000000000ee06de0616177560@google.com/
|
|
|
|
350: lockdep_assert_held(&hugetlb_lock);
|
|
|
|
Should be an issue in hugetlb but triggered in an userfault context, where
|
|
it goes into the unlikely path where two threads modifying the resv map
|
|
together. Mike has a fix in that path for resv uncharge but it looks like
|
|
the locking criteria was overlooked: hugetlb_cgroup_uncharge_folio_rsvd()
|
|
will update the cgroup pointer, so it requires to be called with the lock
|
|
held.(CVE-2024-36000)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
i40e: Do not use WQ_MEM_RECLAIM flag for workqueue
|
|
|
|
Issue reported by customer during SRIOV testing, call trace:
|
|
When both i40e and the i40iw driver are loaded, a warning
|
|
in check_flush_dependency is being triggered. This seems
|
|
to be because of the i40e driver workqueue is allocated with
|
|
the WQ_MEM_RECLAIM flag, and the i40iw one is not.
|
|
|
|
Similar error was encountered on ice too and it was fixed by
|
|
removing the flag. Do the same for i40e too.
|
|
|
|
[Feb 9 09:08] ------------[ cut here ]------------
|
|
[ +0.000004] workqueue: WQ_MEM_RECLAIM i40e:i40e_service_task [i40e] is
|
|
flushing !WQ_MEM_RECLAIM infiniband:0x0
|
|
[ +0.000060] WARNING: CPU: 0 PID: 937 at kernel/workqueue.c:2966
|
|
check_flush_dependency+0x10b/0x120
|
|
[ +0.000007] Modules linked in: snd_seq_dummy snd_hrtimer snd_seq
|
|
snd_timer snd_seq_device snd soundcore nls_utf8 cifs cifs_arc4
|
|
nls_ucs2_utils rdma_cm iw_cm ib_cm cifs_md4 dns_resolver netfs qrtr
|
|
rfkill sunrpc vfat fat intel_rapl_msr intel_rapl_common irdma
|
|
intel_uncore_frequency intel_uncore_frequency_common ice ipmi_ssif
|
|
isst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermal
|
|
intel_powerclamp gnss coretemp ib_uverbs rapl intel_cstate ib_core
|
|
iTCO_wdt iTCO_vendor_support acpi_ipmi mei_me ipmi_si intel_uncore
|
|
ioatdma i2c_i801 joydev pcspkr mei ipmi_devintf lpc_ich
|
|
intel_pch_thermal i2c_smbus ipmi_msghandler acpi_power_meter acpi_pad
|
|
xfs libcrc32c ast sd_mod drm_shmem_helper t10_pi drm_kms_helper sg ixgbe
|
|
drm i40e ahci crct10dif_pclmul libahci crc32_pclmul igb crc32c_intel
|
|
libata ghash_clmulni_intel i2c_algo_bit mdio dca wmi dm_mirror
|
|
dm_region_hash dm_log dm_mod fuse
|
|
[ +0.000050] CPU: 0 PID: 937 Comm: kworker/0:3 Kdump: loaded Not
|
|
tainted 6.8.0-rc2-Feb-net_dev-Qiueue-00279-gbd43c5687e05 #1
|
|
[ +0.000003] Hardware name: Intel Corporation S2600BPB/S2600BPB, BIOS
|
|
SE5C620.86B.02.01.0013.121520200651 12/15/2020
|
|
[ +0.000001] Workqueue: i40e i40e_service_task [i40e]
|
|
[ +0.000024] RIP: 0010:check_flush_dependency+0x10b/0x120
|
|
[ +0.000003] Code: ff 49 8b 54 24 18 48 8d 8b b0 00 00 00 49 89 e8 48
|
|
81 c6 b0 00 00 00 48 c7 c7 b0 97 fa 9f c6 05 8a cc 1f 02 01 e8 35 b3 fd
|
|
ff <0f> 0b e9 10 ff ff ff 80 3d 78 cc 1f 02 00 75 94 e9 46 ff ff ff 90
|
|
[ +0.000002] RSP: 0018:ffffbd294976bcf8 EFLAGS: 00010282
|
|
[ +0.000002] RAX: 0000000000000000 RBX: ffff94d4c483c000 RCX:
|
|
0000000000000027
|
|
[ +0.000001] RDX: ffff94d47f620bc8 RSI: 0000000000000001 RDI:
|
|
ffff94d47f620bc0
|
|
[ +0.000001] RBP: 0000000000000000 R08: 0000000000000000 R09:
|
|
00000000ffff7fff
|
|
[ +0.000001] R10: ffffbd294976bb98 R11: ffffffffa0be65e8 R12:
|
|
ffff94c5451ea180
|
|
[ +0.000001] R13: ffff94c5ab5e8000 R14: ffff94c5c20b6e05 R15:
|
|
ffff94c5f1330ab0
|
|
[ +0.000001] FS: 0000000000000000(0000) GS:ffff94d47f600000(0000)
|
|
knlGS:0000000000000000
|
|
[ +0.000002] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ +0.000001] CR2: 00007f9e6f1fca70 CR3: 0000000038e20004 CR4:
|
|
00000000007706f0
|
|
[ +0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
|
|
0000000000000000
|
|
[ +0.000001] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
|
|
0000000000000400
|
|
[ +0.000001] PKRU: 55555554
|
|
[ +0.000001] Call Trace:
|
|
[ +0.000001] <TASK>
|
|
[ +0.000002] ? __warn+0x80/0x130
|
|
[ +0.000003] ? check_flush_dependency+0x10b/0x120
|
|
[ +0.000002] ? report_bug+0x195/0x1a0
|
|
[ +0.000005] ? handle_bug+0x3c/0x70
|
|
[ +0.000003] ? exc_invalid_op+0x14/0x70
|
|
[ +0.000002] ? asm_exc_invalid_op+0x16/0x20
|
|
[ +0.000006] ? check_flush_dependency+0x10b/0x120
|
|
[ +0.000002] ? check_flush_dependency+0x10b/0x120
|
|
[ +0.000002] __flush_workqueue+0x126/0x3f0
|
|
[ +0.000015] ib_cache_cleanup_one+0x1c/0xe0 [ib_core]
|
|
[ +0.000056] __ib_unregister_device+0x6a/0xb0 [ib_core]
|
|
[ +0.000023] ib_unregister_device_and_put+0x34/0x50 [ib_core]
|
|
[ +0.000020] i40iw_close+0x4b/0x90 [irdma]
|
|
[ +0.000022] i40e_notify_client_of_netdev_close+0x54/0xc0 [i40e]
|
|
[ +0.000035] i40e_service_task+0x126/0x190 [i40e]
|
|
[ +0.000024] process_one_work+0x174/0x340
|
|
[ +0.000003] worker_th
|
|
---truncated---(CVE-2024-36004)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
mlxsw: spectrum_acl_tcam: Fix warning during rehash
|
|
|
|
As previously explained, the rehash delayed work migrates filters from
|
|
one region to another. This is done by iterating over all chunks (all
|
|
the filters with the same priority) in the region and in each chunk
|
|
iterating over all the filters.
|
|
|
|
When the work runs out of credits it stores the current chunk and entry
|
|
as markers in the per-work context so that it would know where to resume
|
|
the migration from the next time the work is scheduled.
|
|
|
|
Upon error, the chunk marker is reset to NULL, but without resetting the
|
|
entry markers despite being relative to it. This can result in migration
|
|
being resumed from an entry that does not belong to the chunk being
|
|
migrated. In turn, this will eventually lead to a chunk being iterated
|
|
over as if it is an entry. Because of how the two structures happen to
|
|
be defined, this does not lead to KASAN splats, but to warnings such as
|
|
[1].
|
|
|
|
Fix by creating a helper that resets all the markers and call it from
|
|
all the places the currently only reset the chunk marker. For good
|
|
measures also call it when starting a completely new rehash. Add a
|
|
warning to avoid future cases.
|
|
|
|
[1]
|
|
WARNING: CPU: 7 PID: 1076 at drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_keys.c:407 mlxsw_afk_encode+0x242/0x2f0
|
|
Modules linked in:
|
|
CPU: 7 PID: 1076 Comm: kworker/7:24 Tainted: G W 6.9.0-rc3-custom-00880-g29e61d91b77b #29
|
|
Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019
|
|
Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work
|
|
RIP: 0010:mlxsw_afk_encode+0x242/0x2f0
|
|
[...]
|
|
Call Trace:
|
|
<TASK>
|
|
mlxsw_sp_acl_atcam_entry_add+0xd9/0x3c0
|
|
mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0
|
|
mlxsw_sp_acl_tcam_vchunk_migrate_all+0x109/0x290
|
|
mlxsw_sp_acl_tcam_vregion_rehash_work+0x6c/0x470
|
|
process_one_work+0x151/0x370
|
|
worker_thread+0x2cb/0x3e0
|
|
kthread+0xd0/0x100
|
|
ret_from_fork+0x34/0x50
|
|
</TASK>(CVE-2024-36007)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ppdev: Add an error check in register_device
|
|
|
|
In register_device, the return value of ida_simple_get is unchecked,
|
|
in witch ida_simple_get will use an invalid index value.
|
|
|
|
To address this issue, index should be checked after ida_simple_get. When
|
|
the index value is abnormal, a warning message should be printed, the port
|
|
should be dropped, and the value should be recorded.(CVE-2024-36015)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
pinctrl: core: delete incorrect free in pinctrl_enable()
|
|
|
|
The "pctldev" struct is allocated in devm_pinctrl_register_and_init().
|
|
It's a devm_ managed pointer that is freed by devm_pinctrl_dev_release(),
|
|
so freeing it in pinctrl_enable() will lead to a double free.
|
|
|
|
The devm_pinctrl_dev_release() function frees the pindescs and destroys
|
|
the mutex as well.(CVE-2024-36940)</Note>
|
|
<Note Title="Topic" Type="General" Ordinal="4" xml:lang="en">An update for kernel is now available for openEuler-22.03-LTS-SP3.
|
|
|
|
openEuler Security has rated this update as having a security impact of 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-1694</URL>
|
|
</Reference>
|
|
<Reference Type="openEuler CVE">
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47265</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47356</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47370</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47427</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2021-47489</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2022-48689</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52654</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52669</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52677</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52696</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52699</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52750</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52752</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52753</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52756</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52759</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52774</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52789</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52795</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52796</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52798</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52799</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52800</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52802</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52814</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52819</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52826</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52831</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52832</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52836</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52838</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52864</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52865</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52871</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52875</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52878</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26833</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26877</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-26934</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27020</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27399</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27401</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27413</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-27415</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35789</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35808</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35822</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35823</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35840</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35855</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35877</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35900</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35904</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35925</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35939</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35950</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35956</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35958</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35960</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35978</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35989</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-36000</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-36004</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-36007</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-36015</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-36940</URL>
|
|
</Reference>
|
|
<Reference Type="Other">
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47265</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47356</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47370</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47427</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2021-47489</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2022-48689</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52654</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52669</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52677</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52696</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52699</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52750</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52752</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52753</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52756</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52759</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52774</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52789</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52795</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52796</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52798</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52799</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52800</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52802</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52814</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52819</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52826</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52831</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52832</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52836</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52838</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52864</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52865</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52871</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52875</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52878</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26833</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26877</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-26934</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27020</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27399</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27401</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27413</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27415</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35789</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35808</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35822</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35823</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35840</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35855</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35877</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35900</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35904</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35925</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35939</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35950</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35956</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35958</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35960</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35978</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35989</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36000</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36004</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36007</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36015</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36940</URL>
|
|
</Reference>
|
|
</DocumentReferences>
|
|
<ProductTree xmlns="http://www.icasi.org/CVRF/schema/prod/1.1">
|
|
<Branch Type="Product Name" Name="openEuler">
|
|
<FullProductName ProductID="openEuler-22.03-LTS-SP3" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">openEuler-22.03-LTS-SP3</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="aarch64">
|
|
<FullProductName ProductID="perf-5.10.0-202.0.0.115" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-5.10.0-202.0.0.115.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-5.10.0-202.0.0.115" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-devel-5.10.0-202.0.0.115.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-5.10.0-202.0.0.115" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-debuginfo-5.10.0-202.0.0.115.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-5.10.0-202.0.0.115" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-5.10.0-202.0.0.115.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-5.10.0-202.0.0.115" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-headers-5.10.0-202.0.0.115.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-5.10.0-202.0.0.115" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-source-5.10.0-202.0.0.115.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-5.10.0-202.0.0.115" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debuginfo-5.10.0-202.0.0.115.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-5.10.0-202.0.0.115" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debugsource-5.10.0-202.0.0.115.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-5.10.0-202.0.0.115" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-5.10.0-202.0.0.115.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-202.0.0.115" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-debuginfo-5.10.0-202.0.0.115.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-5.10.0-202.0.0.115" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-5.10.0-202.0.0.115.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-5.10.0-202.0.0.115" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-devel-5.10.0-202.0.0.115.oe2203sp3.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-202.0.0.115" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-debuginfo-5.10.0-202.0.0.115.oe2203sp3.aarch64.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="src">
|
|
<FullProductName ProductID="kernel-5.10.0-202.0.0.115" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-5.10.0-202.0.0.115.oe2203sp3.src.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="x86_64">
|
|
<FullProductName ProductID="kernel-headers-5.10.0-202.0.0.115" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-headers-5.10.0-202.0.0.115.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-5.10.0-202.0.0.115" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-debuginfo-5.10.0-202.0.0.115.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-5.10.0-202.0.0.115" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">perf-5.10.0-202.0.0.115.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-202.0.0.115" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-debuginfo-5.10.0-202.0.0.115.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-5.10.0-202.0.0.115" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-5.10.0-202.0.0.115.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-5.10.0-202.0.0.115" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-devel-5.10.0-202.0.0.115.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-5.10.0-202.0.0.115" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-devel-5.10.0-202.0.0.115.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-202.0.0.115" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">python3-perf-debuginfo-5.10.0-202.0.0.115.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-5.10.0-202.0.0.115" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debugsource-5.10.0-202.0.0.115.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-5.10.0-202.0.0.115" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-source-5.10.0-202.0.0.115.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-5.10.0-202.0.0.115" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-tools-5.10.0-202.0.0.115.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-5.10.0-202.0.0.115" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-5.10.0-202.0.0.115.oe2203sp3.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-5.10.0-202.0.0.115" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP3">kernel-debuginfo-5.10.0-202.0.0.115.oe2203sp3.x86_64.rpm</FullProductName>
|
|
</Branch>
|
|
</ProductTree>
|
|
<Vulnerability Ordinal="1" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="1" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
RDMA: Verify port when creating flow rule
|
|
|
|
Validate port value provided by the user and with that remove no longer
|
|
needed validation by the driver. The missing check in the mlx5_ib driver
|
|
could cause to the below oops.
|
|
|
|
Call trace:
|
|
_create_flow_rule+0x2d4/0xf28 [mlx5_ib]
|
|
mlx5_ib_create_flow+0x2d0/0x5b0 [mlx5_ib]
|
|
ib_uverbs_ex_create_flow+0x4cc/0x624 [ib_uverbs]
|
|
ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0xd4/0x150 [ib_uverbs]
|
|
ib_uverbs_cmd_verbs.isra.7+0xb28/0xc50 [ib_uverbs]
|
|
ib_uverbs_ioctl+0x158/0x1d0 [ib_uverbs]
|
|
do_vfs_ioctl+0xd0/0xaf0
|
|
ksys_ioctl+0x84/0xb4
|
|
__arm64_sys_ioctl+0x28/0xc4
|
|
el0_svc_common.constprop.3+0xa4/0x254
|
|
el0_svc_handler+0x84/0xa0
|
|
el0_svc+0x10/0x26c
|
|
Code: b9401260 f9615681 51000400 8b001c20 (f9403c1a)</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2021-47265</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</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:
|
|
|
|
mISDN: fix possible use-after-free in HFC_cleanup()
|
|
|
|
This module's remove path calls del_timer(). However, that function
|
|
does not wait until the timer handler finishes. This means that the
|
|
timer handler may still be running after the driver's remove function
|
|
has finished, which would result in a use-after-free.
|
|
|
|
Fix by calling del_timer_sync(), which makes sure the timer handler
|
|
has finished, and unable to re-schedule itself.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2021-47356</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</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:
|
|
|
|
mptcp: ensure tx skbs always have the MPTCP ext
|
|
|
|
Due to signed/unsigned comparison, the expression:
|
|
|
|
info->size_goal - skb->len > 0
|
|
|
|
evaluates to true when the size goal is smaller than the
|
|
skb size. That results in lack of tx cache refill, so that
|
|
the skb allocated by the core TCP code lacks the required
|
|
MPTCP skb extensions.
|
|
|
|
Due to the above, syzbot is able to trigger the following WARN_ON():
|
|
|
|
WARNING: CPU: 1 PID: 810 at net/mptcp/protocol.c:1366 mptcp_sendmsg_frag+0x1362/0x1bc0 net/mptcp/protocol.c:1366
|
|
Modules linked in:
|
|
CPU: 1 PID: 810 Comm: syz-executor.4 Not tainted 5.14.0-syzkaller #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
|
|
RIP: 0010:mptcp_sendmsg_frag+0x1362/0x1bc0 net/mptcp/protocol.c:1366
|
|
Code: ff 4c 8b 74 24 50 48 8b 5c 24 58 e9 0f fb ff ff e8 13 44 8b f8 4c 89 e7 45 31 ed e8 98 57 2e fe e9 81 f4 ff ff e8 fe 43 8b f8 <0f> 0b 41 bd ea ff ff ff e9 6f f4 ff ff 4c 89 e7 e8 b9 8e d2 f8 e9
|
|
RSP: 0018:ffffc9000531f6a0 EFLAGS: 00010216
|
|
RAX: 000000000000697f RBX: 0000000000000000 RCX: ffffc90012107000
|
|
RDX: 0000000000040000 RSI: ffffffff88eac9e2 RDI: 0000000000000003
|
|
RBP: ffff888078b15780 R08: 0000000000000000 R09: 0000000000000000
|
|
R10: ffffffff88eac017 R11: 0000000000000000 R12: ffff88801de0a280
|
|
R13: 0000000000006b58 R14: ffff888066278280 R15: ffff88803c2fe9c0
|
|
FS: 00007fd9f866e700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: 00007faebcb2f718 CR3: 00000000267cb000 CR4: 00000000001506e0
|
|
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
Call Trace:
|
|
__mptcp_push_pending+0x1fb/0x6b0 net/mptcp/protocol.c:1547
|
|
mptcp_release_cb+0xfe/0x210 net/mptcp/protocol.c:3003
|
|
release_sock+0xb4/0x1b0 net/core/sock.c:3206
|
|
sk_stream_wait_memory+0x604/0xed0 net/core/stream.c:145
|
|
mptcp_sendmsg+0xc39/0x1bc0 net/mptcp/protocol.c:1749
|
|
inet6_sendmsg+0x99/0xe0 net/ipv6/af_inet6.c:643
|
|
sock_sendmsg_nosec net/socket.c:704 [inline]
|
|
sock_sendmsg+0xcf/0x120 net/socket.c:724
|
|
sock_write_iter+0x2a0/0x3e0 net/socket.c:1057
|
|
call_write_iter include/linux/fs.h:2163 [inline]
|
|
new_sync_write+0x40b/0x640 fs/read_write.c:507
|
|
vfs_write+0x7cf/0xae0 fs/read_write.c:594
|
|
ksys_write+0x1ee/0x250 fs/read_write.c:647
|
|
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
|
|
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
|
|
entry_SYSCALL_64_after_hwframe+0x44/0xae
|
|
RIP: 0033:0x4665f9
|
|
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
|
|
RSP: 002b:00007fd9f866e188 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
|
|
RAX: ffffffffffffffda RBX: 000000000056c038 RCX: 00000000004665f9
|
|
RDX: 00000000000e7b78 RSI: 0000000020000000 RDI: 0000000000000003
|
|
RBP: 00000000004bfcc4 R08: 0000000000000000 R09: 0000000000000000
|
|
R10: 0000000000000000 R11: 0000000000000246 R12: 000000000056c038
|
|
R13: 0000000000a9fb1f R14: 00007fd9f866e300 R15: 0000000000022000
|
|
|
|
Fix the issue rewriting the relevant expression to avoid
|
|
sign-related problems - note: size_goal is always >= 0.
|
|
|
|
Additionally, ensure that the skb in the tx cache always carries
|
|
the relevant extension.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2021-47370</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</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:
|
|
|
|
scsi: iscsi: Fix iscsi_task use after free
|
|
|
|
Commit d39df158518c ("scsi: iscsi: Have abort handler get ref to conn")
|
|
added iscsi_get_conn()/iscsi_put_conn() calls during abort handling but
|
|
then also changed the handling of the case where we detect an already
|
|
completed task where we now end up doing a goto to the common put/cleanup
|
|
code. This results in a iscsi_task use after free, because the common
|
|
cleanup code will do a put on the iscsi_task.
|
|
|
|
This reverts the goto and moves the iscsi_get_conn() to after we've checked
|
|
if the iscsi_task is valid.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2021-47427</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</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:
|
|
|
|
drm/amdgpu: Fix even more out of bound writes from debugfs
|
|
|
|
CVE-2021-42327 was fixed by:
|
|
|
|
commit f23750b5b3d98653b31d4469592935ef6364ad67
|
|
Author: Thelford Williams <tdwilliamsiv@gmail.com>
|
|
Date: Wed Oct 13 16:04:13 2021 -0400
|
|
|
|
drm/amdgpu: fix out of bounds write
|
|
|
|
but amdgpu_dm_debugfs.c contains more of the same issue so fix the
|
|
remaining ones.
|
|
|
|
v2:
|
|
* Add missing fix in dp_max_bpc_write (Harry Wentland)</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2021-47489</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</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:tcp: TX zerocopy should not sense pfmemalloc statusWe got a recent syzbot report [1] showing a possible misuseof pfmemalloc page status in TCP zerocopy paths.Indeed, for pages coming from user space or other layers,using page_is_pfmemalloc() is moot, and possibly could givefalse positives.There has been attempts to make page_is_pfmemalloc() more robust,but not using it in the first place in this context is probably better,removing cpu cycles.Note to stable teams :You need to backport 84ce071e38a6 ( net: introduce__skb_fill_page_desc_noacc ) as a prereq.Race is more probable after commit c07aea3ef4d4( mm: add a signature in struct page ) because page_is_pfmemalloc()is now using low order bit from page->lru.next, which can changemore often than page->index.Low order bit should never be set for lru.next (when used as an anchorin LRU list), so KCSAN report is mostly a false positive.Backporting to older kernel versions seems not necessary.[1]BUG: KCSAN: data-race in lru_add_fn / tcp_build_fragwrite to 0xffffea0004a1d2c8 of 8 bytes by task 18600 on cpu 0:__list_add include/linux/list.h:73 [inline]list_add include/linux/list.h:88 [inline]lruvec_add_folio include/linux/mm_inline.h:105 [inline]lru_add_fn+0x440/0x520 mm/swap.c:228folio_batch_move_lru+0x1e1/0x2a0 mm/swap.c:246folio_batch_add_and_move mm/swap.c:263 [inline]folio_add_lru+0xf1/0x140 mm/swap.c:490filemap_add_folio+0xf8/0x150 mm/filemap.c:948__filemap_get_folio+0x510/0x6d0 mm/filemap.c:1981pagecache_get_page+0x26/0x190 mm/folio-compat.c:104grab_cache_page_write_begin+0x2a/0x30 mm/folio-compat.c:116ext4_da_write_begin+0x2dd/0x5f0 fs/ext4/inode.c:2988generic_perform_write+0x1d4/0x3f0 mm/filemap.c:3738ext4_buffered_write_iter+0x235/0x3e0 fs/ext4/file.c:270ext4_file_write_iter+0x2e3/0x1210call_write_iter include/linux/fs.h:2187 [inline]new_sync_write fs/read_write.c:491 [inline]vfs_write+0x468/0x760 fs/read_write.c:578ksys_write+0xe8/0x1a0 fs/read_write.c:631__do_sys_write fs/read_write.c:643 [inline]__se_sys_write fs/read_write.c:640 [inline]__x64_sys_write+0x3e/0x50 fs/read_write.c:640do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdread to 0xffffea0004a1d2c8 of 8 bytes by task 18611 on cpu 1:page_is_pfmemalloc include/linux/mm.h:1740 [inline]__skb_fill_page_desc include/linux/skbuff.h:2422 [inline]skb_fill_page_desc include/linux/skbuff.h:2443 [inline]tcp_build_frag+0x613/0xb20 net/ipv4/tcp.c:1018do_tcp_sendpages+0x3e8/0xaf0 net/ipv4/tcp.c:1075tcp_sendpage_locked net/ipv4/tcp.c:1140 [inline]tcp_sendpage+0x89/0xb0 net/ipv4/tcp.c:1150inet_sendpage+0x7f/0xc0 net/ipv4/af_inet.c:833kernel_sendpage+0x184/0x300 net/socket.c:3561sock_sendpage+0x5a/0x70 net/socket.c:1054pipe_to_sendpage+0x128/0x160 fs/splice.c:361splice_from_pipe_feed fs/splice.c:415 [inline]__splice_from_pipe+0x222/0x4d0 fs/splice.c:559splice_from_pipe fs/splice.c:594 [inline]generic_splice_sendpage+0x89/0xc0 fs/splice.c:743do_splice_from fs/splice.c:764 [inline]direct_splice_actor+0x80/0xa0 fs/splice.c:931splice_direct_to_actor+0x305/0x620 fs/splice.c:886do_splice_direct+0xfb/0x180 fs/splice.c:974do_sendfile+0x3bf/0x910 fs/read_write.c:1249__do_sys_sendfile64 fs/read_write.c:1317 [inline]__se_sys_sendfile64 fs/read_write.c:1303 [inline]__x64_sys_sendfile64+0x10c/0x150 fs/read_write.c:1303do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdvalue changed: 0x0000000000000000 -> 0xffffea0004a1d288Reported by Kernel Concurrency Sanitizer on:CPU: 1 PID: 18611 Comm: syz-executor.4 Not tainted 6.0.0-rc2-syzkaller-00248-ge022620b5d05-dirty #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2022-48689</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</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:
|
|
|
|
io_uring/af_unix: disable sending io_uring over sockets
|
|
|
|
File reference cycles have caused lots of problems for io_uring
|
|
in the past, and it still doesn't work exactly right and races with
|
|
unix_stream_read_generic(). The safest fix would be to completely
|
|
disallow sending io_uring files via sockets via SCM_RIGHT, so there
|
|
are no possible cycles invloving registered files and thus rendering
|
|
SCM accounting on the io_uring side unnecessary.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52654</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</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:
|
|
|
|
crypto: s390/aes - Fix buffer overread in CTR mode
|
|
|
|
When processing the last block, the s390 ctr code will always read
|
|
a whole block, even if there isn't a whole block of data left. Fix
|
|
this by using the actual length left and copy it into a buffer first
|
|
for processing.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52669</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</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:
|
|
|
|
riscv: Check if the code to patch lies in the exit section
|
|
|
|
Otherwise we fall through to vmalloc_to_page() which panics since the
|
|
address does not lie in the vmalloc region.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52677</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</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:
|
|
|
|
powerpc/powernv: Add a null pointer check in opal_powercap_init()
|
|
|
|
kasprintf() returns a pointer to dynamically allocated memory
|
|
which can be NULL upon failure.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52696</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</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:
|
|
|
|
sysv: don't call sb_bread() with pointers_lock held
|
|
|
|
syzbot is reporting sleep in atomic context in SysV filesystem [1], for
|
|
sb_bread() is called with rw_spinlock held.
|
|
|
|
A "write_lock(&pointers_lock) => read_lock(&pointers_lock) deadlock" bug
|
|
and a "sb_bread() with write_lock(&pointers_lock)" bug were introduced by
|
|
"Replace BKL for chain locking with sysvfs-private rwlock" in Linux 2.5.12.
|
|
|
|
Then, "[PATCH] err1-40: sysvfs locking fix" in Linux 2.6.8 fixed the
|
|
former bug by moving pointers_lock lock to the callers, but instead
|
|
introduced a "sb_bread() with read_lock(&pointers_lock)" bug (which made
|
|
this problem easier to hit).
|
|
|
|
Al Viro suggested that why not to do like get_branch()/get_block()/
|
|
find_shared() in Minix filesystem does. And doing like that is almost a
|
|
revert of "[PATCH] err1-40: sysvfs locking fix" except that get_branch()
|
|
from with find_shared() is called without write_lock(&pointers_lock).</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52699</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</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:
|
|
|
|
arm64: Restrict CPU_BIG_ENDIAN to GNU as or LLVM IAS 15.x or newer
|
|
|
|
Prior to LLVM 15.0.0, LLVM's integrated assembler would incorrectly
|
|
byte-swap NOP when compiling for big-endian, and the resulting series of
|
|
bytes happened to match the encoding of FNMADD S21, S30, S0, S0.
|
|
|
|
This went unnoticed until commit:
|
|
|
|
34f66c4c4d5518c1 ("arm64: Use a positive cpucap for FP/SIMD")
|
|
|
|
Prior to that commit, the kernel would always enable the use of FPSIMD
|
|
early in boot when __cpu_setup() initialized CPACR_EL1, and so usage of
|
|
FNMADD within the kernel was not detected, but could result in the
|
|
corruption of user or kernel FPSIMD state.
|
|
|
|
After that commit, the instructions happen to trap during boot prior to
|
|
FPSIMD being detected and enabled, e.g.
|
|
|
|
| Unhandled 64-bit el1h sync exception on CPU0, ESR 0x000000001fe00000 -- ASIMD
|
|
| CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1
|
|
| Hardware name: linux,dummy-virt (DT)
|
|
| pstate: 400000c9 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
|
|
| pc : __pi_strcmp+0x1c/0x150
|
|
| lr : populate_properties+0xe4/0x254
|
|
| sp : ffffd014173d3ad0
|
|
| x29: ffffd014173d3af0 x28: fffffbfffddffcb8 x27: 0000000000000000
|
|
| x26: 0000000000000058 x25: fffffbfffddfe054 x24: 0000000000000008
|
|
| x23: fffffbfffddfe000 x22: fffffbfffddfe000 x21: fffffbfffddfe044
|
|
| x20: ffffd014173d3b70 x19: 0000000000000001 x18: 0000000000000005
|
|
| x17: 0000000000000010 x16: 0000000000000000 x15: 00000000413e7000
|
|
| x14: 0000000000000000 x13: 0000000000001bcc x12: 0000000000000000
|
|
| x11: 00000000d00dfeed x10: ffffd414193f2cd0 x9 : 0000000000000000
|
|
| x8 : 0101010101010101 x7 : ffffffffffffffc0 x6 : 0000000000000000
|
|
| x5 : 0000000000000000 x4 : 0101010101010101 x3 : 000000000000002a
|
|
| x2 : 0000000000000001 x1 : ffffd014171f2988 x0 : fffffbfffddffcb8
|
|
| Kernel panic - not syncing: Unhandled exception
|
|
| CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1
|
|
| Hardware name: linux,dummy-virt (DT)
|
|
| Call trace:
|
|
| dump_backtrace+0xec/0x108
|
|
| show_stack+0x18/0x2c
|
|
| dump_stack_lvl+0x50/0x68
|
|
| dump_stack+0x18/0x24
|
|
| panic+0x13c/0x340
|
|
| el1t_64_irq_handler+0x0/0x1c
|
|
| el1_abort+0x0/0x5c
|
|
| el1h_64_sync+0x64/0x68
|
|
| __pi_strcmp+0x1c/0x150
|
|
| unflatten_dt_nodes+0x1e8/0x2d8
|
|
| __unflatten_device_tree+0x5c/0x15c
|
|
| unflatten_device_tree+0x38/0x50
|
|
| setup_arch+0x164/0x1e0
|
|
| start_kernel+0x64/0x38c
|
|
| __primary_switched+0xbc/0xc4
|
|
|
|
Restrict CONFIG_CPU_BIG_ENDIAN to a known good assembler, which is
|
|
either GNU as or LLVM's IAS 15.0.0 and newer, which contains the linked
|
|
commit.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52750</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</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:smb: client: fix use-after-free bug in cifs_debug_data_proc_show()Skip SMB sessions that are being teared down(e.g. @ses->ses_status == SES_EXITING) in cifs_debug_data_proc_show()to avoid use-after-free in @ses.This fixes the following GPF when reading from /proc/fs/cifs/DebugDatawhile mounting and umounting [ 816.251274] general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6d81: 0000 [#1] PREEMPT SMP NOPTI ... [ 816.260138] Call Trace: [ 816.260329] <TASK> [ 816.260499] ? die_addr+0x36/0x90 [ 816.260762] ? exc_general_protection+0x1b3/0x410 [ 816.261126] ? asm_exc_general_protection+0x26/0x30 [ 816.261502] ? cifs_debug_tcon+0xbd/0x240 [cifs] [ 816.261878] ? cifs_debug_tcon+0xab/0x240 [cifs] [ 816.262249] cifs_debug_data_proc_show+0x516/0xdb0 [cifs] [ 816.262689] ? seq_read_iter+0x379/0x470 [ 816.262995] seq_read_iter+0x118/0x470 [ 816.263291] proc_reg_read_iter+0x53/0x90 [ 816.263596] ? srso_alias_return_thunk+0x5/0x7f [ 816.263945] vfs_read+0x201/0x350 [ 816.264211] ksys_read+0x75/0x100 [ 816.264472] do_syscall_64+0x3f/0x90 [ 816.264750] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ 816.265135] RIP: 0033:0x7fd5e669d381</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52752</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</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:
|
|
|
|
drm/amd/display: Avoid NULL dereference of timing generator
|
|
|
|
[Why & How]
|
|
Check whether assigned timing generator is NULL or not before
|
|
accessing its funcs to prevent NULL dereference.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52753</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</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:
|
|
|
|
pwm: Fix double shift bug
|
|
|
|
These enums are passed to set/test_bit(). The set/test_bit() functions
|
|
take a bit number instead of a shifted value. Passing a shifted value
|
|
is a double shift bug like doing BIT(BIT(1)). The double shift bug
|
|
doesn't cause a problem here because we are only checking 0 and 1 but
|
|
if the value was 5 or above then it can lead to a buffer overflow.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52756</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</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:
|
|
|
|
gfs2: ignore negated quota changes
|
|
|
|
When lots of quota changes are made, there may be cases in which an
|
|
inode's quota information is increased and then decreased, such as when
|
|
blocks are added to a file, then deleted from it. If the timing is
|
|
right, function do_qc can add pending quota changes to a transaction,
|
|
then later, another call to do_qc can negate those changes, resulting
|
|
in a net gain of 0. The quota_change information is recorded in the qc
|
|
buffer (and qd element of the inode as well). The buffer is added to the
|
|
transaction by the first call to do_qc, but a subsequent call changes
|
|
the value from non-zero back to zero. At that point it's too late to
|
|
remove the buffer_head from the transaction. Later, when the quota sync
|
|
code is called, the zero-change qd element is discovered and flagged as
|
|
an assert warning. If the fs is mounted with errors=panic, the kernel
|
|
will panic.
|
|
|
|
This is usually seen when files are truncated and the quota changes are
|
|
negated by punch_hole/truncate which uses gfs2_quota_hold and
|
|
gfs2_quota_unhold rather than block allocations that use gfs2_quota_lock
|
|
and gfs2_quota_unlock which automatically do quota sync.
|
|
|
|
This patch solves the problem by adding a check to qd_check_sync such
|
|
that net-zero quota changes already added to the transaction are no
|
|
longer deemed necessary to be synced, and skipped.
|
|
|
|
In this case references are taken for the qd and the slot from do_qc
|
|
so those need to be put. The normal sequence of events for a normal
|
|
non-zero quota change is as follows:
|
|
|
|
gfs2_quota_change
|
|
do_qc
|
|
qd_hold
|
|
slot_hold
|
|
|
|
Later, when the changes are to be synced:
|
|
|
|
gfs2_quota_sync
|
|
qd_fish
|
|
qd_check_sync
|
|
gets qd ref via lockref_get_not_dead
|
|
do_sync
|
|
do_qc(QC_SYNC)
|
|
qd_put
|
|
lockref_put_or_lock
|
|
qd_unlock
|
|
qd_put
|
|
lockref_put_or_lock
|
|
|
|
In the net-zero change case, we add a check to qd_check_sync so it puts
|
|
the qd and slot references acquired in gfs2_quota_change and skip the
|
|
unneeded sync.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52759</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</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:
|
|
|
|
s390/dasd: protect device queue against concurrent access
|
|
|
|
In dasd_profile_start() the amount of requests on the device queue are
|
|
counted. The access to the device queue is unprotected against
|
|
concurrent access. With a lot of parallel I/O, especially with alias
|
|
devices enabled, the device queue can change while dasd_profile_start()
|
|
is accessing the queue. In the worst case this leads to a kernel panic
|
|
due to incorrect pointer accesses.
|
|
|
|
Fix this by taking the device lock before accessing the queue and
|
|
counting the requests. Additionally the check for a valid profile data
|
|
pointer can be done earlier to avoid unnecessary locking in a hot path.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52774</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</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:
|
|
|
|
tty: vcc: Add check for kstrdup() in vcc_probe()
|
|
|
|
Add check for the return value of kstrdup() and return the error, if it
|
|
fails in order to avoid NULL pointer dereference.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52789</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</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:
|
|
|
|
vhost-vdpa: fix use after free in vhost_vdpa_probe()
|
|
|
|
The put_device() calls vhost_vdpa_release_dev() which calls
|
|
ida_simple_remove() and frees "v". So this call to
|
|
ida_simple_remove() is a use after free and a double free.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52795</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>0.0</BaseScore>
|
|
<Vector></Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</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:
|
|
|
|
ipvlan: add ipvlan_route_v6_outbound() helper
|
|
|
|
Inspired by syzbot reports using a stack of multiple ipvlan devices.
|
|
|
|
Reduce stack size needed in ipvlan_process_v6_outbound() by moving
|
|
the flowi6 struct used for the route lookup in an non inlined
|
|
helper. ipvlan_route_v6_outbound() needs 120 bytes on the stack,
|
|
immediately reclaimed.
|
|
|
|
Also make sure ipvlan_process_v4_outbound() is not inlined.
|
|
|
|
We might also have to lower MAX_NEST_DEV, because only syzbot uses
|
|
setups with more than four stacked devices.
|
|
|
|
BUG: TASK stack guard page was hit at ffffc9000e803ff8 (stack is ffffc9000e804000..ffffc9000e808000)
|
|
stack guard page: 0000 [#1] SMP KASAN
|
|
CPU: 0 PID: 13442 Comm: syz-executor.4 Not tainted 6.1.52-syzkaller #0
|
|
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023
|
|
RIP: 0010:kasan_check_range+0x4/0x2a0 mm/kasan/generic.c:188
|
|
Code: 48 01 c6 48 89 c7 e8 db 4e c1 03 31 c0 5d c3 cc 0f 0b eb 02 0f 0b b8 ea ff ff ff 5d c3 cc 00 00 cc cc 00 00 cc cc 55 48 89 e5 <41> 57 41 56 41 55 41 54 53 b0 01 48 85 f6 0f 84 a4 01 00 00 48 89
|
|
RSP: 0018:ffffc9000e804000 EFLAGS: 00010246
|
|
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817e5bf2
|
|
RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffff887c6568
|
|
RBP: ffffc9000e804000 R08: 0000000000000000 R09: 0000000000000000
|
|
R10: 0000000000000000 R11: dffffc0000000001 R12: 1ffff92001d0080c
|
|
R13: dffffc0000000000 R14: ffffffff87e6b100 R15: 0000000000000000
|
|
FS: 00007fd0c55826c0(0000) GS:ffff8881f6800000(0000) knlGS:0000000000000000
|
|
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
CR2: ffffc9000e803ff8 CR3: 0000000170ef7000 CR4: 00000000003506f0
|
|
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
|
|
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
|
|
Call Trace:
|
|
<#DF>
|
|
</#DF>
|
|
<TASK>
|
|
[<ffffffff81f281d1>] __kasan_check_read+0x11/0x20 mm/kasan/shadow.c:31
|
|
[<ffffffff817e5bf2>] instrument_atomic_read include/linux/instrumented.h:72 [inline]
|
|
[<ffffffff817e5bf2>] _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]
|
|
[<ffffffff817e5bf2>] cpumask_test_cpu include/linux/cpumask.h:506 [inline]
|
|
[<ffffffff817e5bf2>] cpu_online include/linux/cpumask.h:1092 [inline]
|
|
[<ffffffff817e5bf2>] trace_lock_acquire include/trace/events/lock.h:24 [inline]
|
|
[<ffffffff817e5bf2>] lock_acquire+0xe2/0x590 kernel/locking/lockdep.c:5632
|
|
[<ffffffff8563221e>] rcu_lock_acquire+0x2e/0x40 include/linux/rcupdate.h:306
|
|
[<ffffffff8561464d>] rcu_read_lock include/linux/rcupdate.h:747 [inline]
|
|
[<ffffffff8561464d>] ip6_pol_route+0x15d/0x1440 net/ipv6/route.c:2221
|
|
[<ffffffff85618120>] ip6_pol_route_output+0x50/0x80 net/ipv6/route.c:2606
|
|
[<ffffffff856f65b5>] pol_lookup_func include/net/ip6_fib.h:584 [inline]
|
|
[<ffffffff856f65b5>] fib6_rule_lookup+0x265/0x620 net/ipv6/fib6_rules.c:116
|
|
[<ffffffff85618009>] ip6_route_output_flags_noref+0x2d9/0x3a0 net/ipv6/route.c:2638
|
|
[<ffffffff8561821a>] ip6_route_output_flags+0xca/0x340 net/ipv6/route.c:2651
|
|
[<ffffffff838bd5a3>] ip6_route_output include/net/ip6_route.h:100 [inline]
|
|
[<ffffffff838bd5a3>] ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:473 [inline]
|
|
[<ffffffff838bd5a3>] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:529 [inline]
|
|
[<ffffffff838bd5a3>] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline]
|
|
[<ffffffff838bd5a3>] ipvlan_queue_xmit+0xc33/0x1be0 drivers/net/ipvlan/ipvlan_core.c:677
|
|
[<ffffffff838c2909>] ipvlan_start_xmit+0x49/0x100 drivers/net/ipvlan/ipvlan_main.c:229
|
|
[<ffffffff84d03900>] netdev_start_xmit include/linux/netdevice.h:4966 [inline]
|
|
[<ffffffff84d03900>] xmit_one net/core/dev.c:3644 [inline]
|
|
[<ffffffff84d03900>] dev_hard_start_xmit+0x320/0x980 net/core/dev.c:3660
|
|
[<ffffffff84d080e2>] __dev_queue_xmit+0x16b2/0x3370 net/core/dev.c:4324
|
|
[<ffffffff855ce4cd>] dev_queue_xmit include/linux/netdevice.h:3067 [inline]
|
|
[<ffffffff855ce4cd>] neigh_hh_output include/net/neighbour.h:529 [inline]
|
|
[<f
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52796</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</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:
|
|
|
|
wifi: ath11k: fix dfs radar event locking
|
|
|
|
The ath11k active pdevs are protected by RCU but the DFS radar event
|
|
handling code calling ath11k_mac_get_ar_by_pdev_id() was not marked as a
|
|
read-side critical section.
|
|
|
|
Mark the code in question as an RCU read-side critical section to avoid
|
|
any potential use-after-free issues.
|
|
|
|
Compile tested only.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52798</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</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:
|
|
|
|
jfs: fix array-index-out-of-bounds in dbFindLeaf
|
|
|
|
Currently while searching for dmtree_t for sufficient free blocks there
|
|
is an array out of bounds while getting element in tp->dm_stree. To add
|
|
the required check for out of bound we first need to determine the type
|
|
of dmtree. Thus added an extra parameter to dbFindLeaf so that the type
|
|
of tree can be determined and the required check can be applied.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52799</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="23" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="23" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: ath11k: fix htt pktlog locking
|
|
|
|
The ath11k active pdevs are protected by RCU but the htt pktlog handling
|
|
code calling ath11k_mac_get_ar_by_pdev_id() was not marked as a
|
|
read-side critical section.
|
|
|
|
Mark the code in question as an RCU read-side critical section to avoid
|
|
any potential use-after-free issues.
|
|
|
|
Compile tested only.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52800</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</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:iio: adc: stm32-adc: harden against NULL pointer deref in stm32_adc_probe()of_match_device() may fail and returns a NULL pointer.In practice there is no known reasonable way to trigger this, butin case one is added in future, harden the code by adding the check</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52802</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</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:drm/amdgpu: Fix potential null pointer derefernceThe amdgpu_ras_get_context may return NULL if devicenot support ras feature, so add check before using.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52814</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</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:
|
|
|
|
drm/amd: Fix UBSAN array-index-out-of-bounds for Polaris and Tonga
|
|
|
|
For pptable structs that use flexible array sizes, use flexible arrays.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52819</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</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:
|
|
|
|
drm/panel/panel-tpo-tpg110: fix a possible null pointer dereference
|
|
|
|
In tpg110_get_modes(), the return value of drm_mode_duplicate() is
|
|
assigned to mode, which will lead to a NULL pointer dereference on
|
|
failure of drm_mode_duplicate(). Add a check to avoid npd.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52826</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</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:
|
|
|
|
cpu/hotplug: Don't offline the last non-isolated CPU
|
|
|
|
If a system has isolated CPUs via the "isolcpus=" command line parameter,
|
|
then an attempt to offline the last housekeeping CPU will result in a
|
|
WARN_ON() when rebuilding the scheduler domains and a subsequent panic due
|
|
to and unhandled empty CPU mas in partition_sched_domains_locked().
|
|
|
|
cpuset_hotplug_workfn()
|
|
rebuild_sched_domains_locked()
|
|
ndoms = generate_sched_domains(&doms, &attr);
|
|
cpumask_and(doms[0], top_cpuset.effective_cpus, housekeeping_cpumask(HK_FLAG_DOMAIN));
|
|
|
|
Thus results in an empty CPU mask which triggers the warning and then the
|
|
subsequent crash:
|
|
|
|
WARNING: CPU: 4 PID: 80 at kernel/sched/topology.c:2366 build_sched_domains+0x120c/0x1408
|
|
Call trace:
|
|
build_sched_domains+0x120c/0x1408
|
|
partition_sched_domains_locked+0x234/0x880
|
|
rebuild_sched_domains_locked+0x37c/0x798
|
|
rebuild_sched_domains+0x30/0x58
|
|
cpuset_hotplug_workfn+0x2a8/0x930
|
|
|
|
Unable to handle kernel paging request at virtual address fffe80027ab37080
|
|
partition_sched_domains_locked+0x318/0x880
|
|
rebuild_sched_domains_locked+0x37c/0x798
|
|
|
|
Aside of the resulting crash, it does not make any sense to offline the last
|
|
last housekeeping CPU.
|
|
|
|
Prevent this by masking out the non-housekeeping CPUs when selecting a
|
|
target CPU for initiating the CPU unplug operation via the work queue.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52831</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</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:
|
|
|
|
wifi: mac80211: don't return unset power in ieee80211_get_tx_power()
|
|
|
|
We can get a UBSAN warning if ieee80211_get_tx_power() returns the
|
|
INT_MIN value mac80211 internally uses for "unset power level".
|
|
|
|
UBSAN: signed-integer-overflow in net/wireless/nl80211.c:3816:5
|
|
-2147483648 * 100 cannot be represented in type 'int'
|
|
CPU: 0 PID: 20433 Comm: insmod Tainted: G WC OE
|
|
Call Trace:
|
|
dump_stack+0x74/0x92
|
|
ubsan_epilogue+0x9/0x50
|
|
handle_overflow+0x8d/0xd0
|
|
__ubsan_handle_mul_overflow+0xe/0x10
|
|
nl80211_send_iface+0x688/0x6b0 [cfg80211]
|
|
[...]
|
|
cfg80211_register_wdev+0x78/0xb0 [cfg80211]
|
|
cfg80211_netdev_notifier_call+0x200/0x620 [cfg80211]
|
|
[...]
|
|
ieee80211_if_add+0x60e/0x8f0 [mac80211]
|
|
ieee80211_register_hw+0xda5/0x1170 [mac80211]
|
|
|
|
In this case, simply return an error instead, to indicate
|
|
that no data is available.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52832</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</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:
|
|
|
|
locking/ww_mutex/test: Fix potential workqueue corruption
|
|
|
|
In some cases running with the test-ww_mutex code, I was seeing
|
|
odd behavior where sometimes it seemed flush_workqueue was
|
|
returning before all the work threads were finished.
|
|
|
|
Often this would cause strange crashes as the mutexes would be
|
|
freed while they were being used.
|
|
|
|
Looking at the code, there is a lifetime problem as the
|
|
controlling thread that spawns the work allocates the
|
|
"struct stress" structures that are passed to the workqueue
|
|
threads. Then when the workqueue threads are finished,
|
|
they free the stress struct that was passed to them.
|
|
|
|
Unfortunately the workqueue work_struct node is in the stress
|
|
struct. Which means the work_struct is freed before the work
|
|
thread returns and while flush_workqueue is waiting.
|
|
|
|
It seems like a better idea to have the controlling thread
|
|
both allocate and free the stress structures, so that we can
|
|
be sure we don't corrupt the workqueue by freeing the structure
|
|
prematurely.
|
|
|
|
So this patch reworks the test to do so, and with this change
|
|
I no longer see the early flush_workqueue returns.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52836</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</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:
|
|
|
|
fbdev: imsttfb: fix a resource leak in probe
|
|
|
|
I've re-written the error handling but the bug is that if init_imstt()
|
|
fails we need to call iounmap(par->cmap_regs).</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52838</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</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:
|
|
|
|
platform/x86: wmi: Fix opening of char device
|
|
|
|
Since commit fa1f68db6ca7 ("drivers: misc: pass miscdevice pointer via
|
|
file private data"), the miscdevice stores a pointer to itself inside
|
|
filp->private_data, which means that private_data will not be NULL when
|
|
wmi_char_open() is called. This might cause memory corruption should
|
|
wmi_char_open() be unable to find its driver, something which can
|
|
happen when the associated WMI device is deleted in wmi_free_devices().
|
|
|
|
Fix the problem by using the miscdevice pointer to retrieve the WMI
|
|
device data associated with a char device using container_of(). This
|
|
also avoids wmi_char_open() picking a wrong WMI device bound to a
|
|
driver with the same name as the original driver.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52864</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</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:
|
|
|
|
clk: mediatek: clk-mt6797: Add check for mtk_alloc_clk_data
|
|
|
|
Add the check for the return value of mtk_alloc_clk_data() in order to
|
|
avoid NULL pointer dereference.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52865</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</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:
|
|
|
|
soc: qcom: llcc: Handle a second device without data corruption
|
|
|
|
Usually there is only one llcc device. But if there were a second, even
|
|
a failed probe call would modify the global drv_data pointer. So check
|
|
if drv_data is valid before overwriting it.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52871</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="35" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="35" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
clk: mediatek: clk-mt2701: Add check for mtk_alloc_clk_data
|
|
|
|
Add the check for the return value of mtk_alloc_clk_data() in order to
|
|
avoid NULL pointer dereference.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52875</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="36" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="36" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
can: dev: can_put_echo_skb(): don't crash kernel if can_priv::echo_skb is accessed out of bounds
|
|
|
|
If the "struct can_priv::echoo_skb" is accessed out of bounds, this
|
|
would cause a kernel crash. Instead, issue a meaningful warning
|
|
message and return with an error.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52878</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="37" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="37" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/amd/display: Fix memory leak in dm_sw_fini()
|
|
|
|
After destroying dmub_srv, the memory associated with it is
|
|
not freed, causing a memory leak:
|
|
|
|
unreferenced object 0xffff896302b45800 (size 1024):
|
|
comm "(udev-worker)", pid 222, jiffies 4294894636
|
|
hex dump (first 32 bytes):
|
|
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
backtrace (crc 6265fd77):
|
|
[<ffffffff993495ed>] kmalloc_trace+0x29d/0x340
|
|
[<ffffffffc0ea4a94>] dm_dmub_sw_init+0xb4/0x450 [amdgpu]
|
|
[<ffffffffc0ea4e55>] dm_sw_init+0x15/0x2b0 [amdgpu]
|
|
[<ffffffffc0ba8557>] amdgpu_device_init+0x1417/0x24e0 [amdgpu]
|
|
[<ffffffffc0bab285>] amdgpu_driver_load_kms+0x15/0x190 [amdgpu]
|
|
[<ffffffffc0ba09c7>] amdgpu_pci_probe+0x187/0x4e0 [amdgpu]
|
|
[<ffffffff9968fd1e>] local_pci_probe+0x3e/0x90
|
|
[<ffffffff996918a3>] pci_device_probe+0xc3/0x230
|
|
[<ffffffff99805872>] really_probe+0xe2/0x480
|
|
[<ffffffff99805c98>] __driver_probe_device+0x78/0x160
|
|
[<ffffffff99805daf>] driver_probe_device+0x1f/0x90
|
|
[<ffffffff9980601e>] __driver_attach+0xce/0x1c0
|
|
[<ffffffff99803170>] bus_for_each_dev+0x70/0xc0
|
|
[<ffffffff99804822>] bus_add_driver+0x112/0x210
|
|
[<ffffffff99807245>] driver_register+0x55/0x100
|
|
[<ffffffff990012d1>] do_one_initcall+0x41/0x300
|
|
|
|
Fix this by freeing dmub_srv after destroying it.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2024-26833</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="38" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="38" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
crypto: xilinx - call finalize with bh disabled
|
|
|
|
When calling crypto_finalize_request, BH should be disabled to avoid
|
|
triggering the following calltrace:
|
|
|
|
------------[ cut here ]------------
|
|
WARNING: CPU: 2 PID: 74 at crypto/crypto_engine.c:58 crypto_finalize_request+0xa0/0x118
|
|
Modules linked in: cryptodev(O)
|
|
CPU: 2 PID: 74 Comm: firmware:zynqmp Tainted: G O 6.8.0-rc1-yocto-standard #323
|
|
Hardware name: ZynqMP ZCU102 Rev1.0 (DT)
|
|
pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
|
|
pc : crypto_finalize_request+0xa0/0x118
|
|
lr : crypto_finalize_request+0x104/0x118
|
|
sp : ffffffc085353ce0
|
|
x29: ffffffc085353ce0 x28: 0000000000000000 x27: ffffff8808ea8688
|
|
x26: ffffffc081715038 x25: 0000000000000000 x24: ffffff880100db00
|
|
x23: ffffff880100da80 x22: 0000000000000000 x21: 0000000000000000
|
|
x20: ffffff8805b14000 x19: ffffff880100da80 x18: 0000000000010450
|
|
x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
|
|
x14: 0000000000000003 x13: 0000000000000000 x12: ffffff880100dad0
|
|
x11: 0000000000000000 x10: ffffffc0832dcd08 x9 : ffffffc0812416d8
|
|
x8 : 00000000000001f4 x7 : ffffffc0830d2830 x6 : 0000000000000001
|
|
x5 : ffffffc082091000 x4 : ffffffc082091658 x3 : 0000000000000000
|
|
x2 : ffffffc7f9653000 x1 : 0000000000000000 x0 : ffffff8802d20000
|
|
Call trace:
|
|
crypto_finalize_request+0xa0/0x118
|
|
crypto_finalize_aead_request+0x18/0x30
|
|
zynqmp_handle_aes_req+0xcc/0x388
|
|
crypto_pump_work+0x168/0x2d8
|
|
kthread_worker_fn+0xfc/0x3a0
|
|
kthread+0x118/0x138
|
|
ret_from_fork+0x10/0x20
|
|
irq event stamp: 40
|
|
hardirqs last enabled at (39): [<ffffffc0812416f8>] _raw_spin_unlock_irqrestore+0x70/0xb0
|
|
hardirqs last disabled at (40): [<ffffffc08122d208>] el1_dbg+0x28/0x90
|
|
softirqs last enabled at (36): [<ffffffc080017dec>] kernel_neon_begin+0x8c/0xf0
|
|
softirqs last disabled at (34): [<ffffffc080017dc0>] kernel_neon_begin+0x60/0xf0
|
|
---[ end trace 0000000000000000 ]---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2024-26877</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>3.3</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="39" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="39" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:USB: core: Fix deadlock in usb_deauthorize_interface()Among the attribute file callback routines indrivers/usb/core/sysfs.c, the interface_authorized_store() function isthe only one which acquires a device lock on an ancestor device: Itcalls usb_deauthorize_interface(), which locks the interface s parentUSB device.The will lead to deadlock if another process already owns that lockand tries to remove the interface, whether through a configurationchange or because the device has been disconnected. As part of theremoval procedure, device_del() waits for all ongoing sysfs attributecallbacks to complete. But usb_deauthorize_interface() can t completeuntil the device lock has been released, and the lock won t bereleased until the removal has finished.The mechanism provided by sysfs to prevent this kind of deadlock isto use the sysfs_break_active_protection() function, which tells sysfsnot to wait for the attribute callback.Reported-and-tested by: Yue Sun <samsun1006219@gmail.com>Reported by: xingwei lee <xrivendell7@gmail.com></Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2024-26934</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="40" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="40" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: Fix potential data-race in __nft_expr_type_get()nft_unregister_expr() can concurrent with __nft_expr_type_get(),and there is not any protection when iterate over nf_tables_expressionslist in __nft_expr_type_get(). Therefore, there is potential data-raceof nf_tables_expressions list entry.Use list_for_each_entry_rcu() to iterate over nf_tables_expressionslist in __nft_expr_type_get(), and use rcu_read_lock() in the callernft_expr_type_get() to protect the entire type query process.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2024-27020</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="41" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="41" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
Bluetooth: l2cap: fix null-ptr-deref in l2cap_chan_timeout
|
|
|
|
There is a race condition between l2cap_chan_timeout() and
|
|
l2cap_chan_del(). When we use l2cap_chan_del() to delete the
|
|
channel, the chan->conn will be set to null. But the conn could
|
|
be dereferenced again in the mutex_lock() of l2cap_chan_timeout().
|
|
As a result the null pointer dereference bug will happen. The
|
|
KASAN report triggered by POC is shown below:
|
|
|
|
[ 472.074580] ==================================================================
|
|
[ 472.075284] BUG: KASAN: null-ptr-deref in mutex_lock+0x68/0xc0
|
|
[ 472.075308] Write of size 8 at addr 0000000000000158 by task kworker/0:0/7
|
|
[ 472.075308]
|
|
[ 472.075308] CPU: 0 PID: 7 Comm: kworker/0:0 Not tainted 6.9.0-rc5-00356-g78c0094a146b #36
|
|
[ 472.075308] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4
|
|
[ 472.075308] Workqueue: events l2cap_chan_timeout
|
|
[ 472.075308] Call Trace:
|
|
[ 472.075308] <TASK>
|
|
[ 472.075308] dump_stack_lvl+0x137/0x1a0
|
|
[ 472.075308] print_report+0x101/0x250
|
|
[ 472.075308] ? __virt_addr_valid+0x77/0x160
|
|
[ 472.075308] ? mutex_lock+0x68/0xc0
|
|
[ 472.075308] kasan_report+0x139/0x170
|
|
[ 472.075308] ? mutex_lock+0x68/0xc0
|
|
[ 472.075308] kasan_check_range+0x2c3/0x2e0
|
|
[ 472.075308] mutex_lock+0x68/0xc0
|
|
[ 472.075308] l2cap_chan_timeout+0x181/0x300
|
|
[ 472.075308] process_one_work+0x5d2/0xe00
|
|
[ 472.075308] worker_thread+0xe1d/0x1660
|
|
[ 472.075308] ? pr_cont_work+0x5e0/0x5e0
|
|
[ 472.075308] kthread+0x2b7/0x350
|
|
[ 472.075308] ? pr_cont_work+0x5e0/0x5e0
|
|
[ 472.075308] ? kthread_blkcg+0xd0/0xd0
|
|
[ 472.075308] ret_from_fork+0x4d/0x80
|
|
[ 472.075308] ? kthread_blkcg+0xd0/0xd0
|
|
[ 472.075308] ret_from_fork_asm+0x11/0x20
|
|
[ 472.075308] </TASK>
|
|
[ 472.075308] ==================================================================
|
|
[ 472.094860] Disabling lock debugging due to kernel taint
|
|
[ 472.096136] BUG: kernel NULL pointer dereference, address: 0000000000000158
|
|
[ 472.096136] #PF: supervisor write access in kernel mode
|
|
[ 472.096136] #PF: error_code(0x0002) - not-present page
|
|
[ 472.096136] PGD 0 P4D 0
|
|
[ 472.096136] Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI
|
|
[ 472.096136] CPU: 0 PID: 7 Comm: kworker/0:0 Tainted: G B 6.9.0-rc5-00356-g78c0094a146b #36
|
|
[ 472.096136] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4
|
|
[ 472.096136] Workqueue: events l2cap_chan_timeout
|
|
[ 472.096136] RIP: 0010:mutex_lock+0x88/0xc0
|
|
[ 472.096136] Code: be 08 00 00 00 e8 f8 23 1f fd 4c 89 f7 be 08 00 00 00 e8 eb 23 1f fd 42 80 3c 23 00 74 08 48 88
|
|
[ 472.096136] RSP: 0018:ffff88800744fc78 EFLAGS: 00000246
|
|
[ 472.096136] RAX: 0000000000000000 RBX: 1ffff11000e89f8f RCX: ffffffff8457c865
|
|
[ 472.096136] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffff88800744fc78
|
|
[ 472.096136] RBP: 0000000000000158 R08: ffff88800744fc7f R09: 1ffff11000e89f8f
|
|
[ 472.096136] R10: dffffc0000000000 R11: ffffed1000e89f90 R12: dffffc0000000000
|
|
[ 472.096136] R13: 0000000000000158 R14: ffff88800744fc78 R15: ffff888007405a00
|
|
[ 472.096136] FS: 0000000000000000(0000) GS:ffff88806d200000(0000) knlGS:0000000000000000
|
|
[ 472.096136] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ 472.096136] CR2: 0000000000000158 CR3: 000000000da32000 CR4: 00000000000006f0
|
|
[ 472.096136] Call Trace:
|
|
[ 472.096136] <TASK>
|
|
[ 472.096136] ? __die_body+0x8d/0xe0
|
|
[ 472.096136] ? page_fault_oops+0x6b8/0x9a0
|
|
[ 472.096136] ? kernelmode_fixup_or_oops+0x20c/0x2a0
|
|
[ 472.096136] ? do_user_addr_fault+0x1027/0x1340
|
|
[ 472.096136] ? _printk+0x7a/0xa0
|
|
[ 472.096136] ? mutex_lock+0x68/0xc0
|
|
[ 472.096136] ? add_taint+0x42/0xd0
|
|
[ 472.096136] ? exc_page_fault+0x6a/0x1b0
|
|
[ 472.096136] ? asm_exc_page_fault+0x26/0x30
|
|
[ 472.096136] ? mutex_lock+0x75/0xc0
|
|
[ 472.096136] ? mutex_lock+0x88/0xc0
|
|
[ 472.096136] ? mutex_lock+0x75/0xc0
|
|
[ 472.096136] l2cap_chan_timeo
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2024-27399</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="42" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="42" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
firewire: nosy: ensure user_length is taken into account when fetching packet contents
|
|
|
|
Ensure that packet_buffer_get respects the user_length provided. If
|
|
the length of the head packet exceeds the user_length, packet_buffer_get
|
|
will now return 0 to signify to the user that no data were read
|
|
and a larger buffer size is required. Helps prevent user space overflows.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2024-27401</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H</Vector>
|
|
</ScoreSet>
|
|
</CVSSScoreSets>
|
|
<Remediations>
|
|
<Remediation Type="Vendor Fix">
|
|
<Description>kernel security update</Description>
|
|
<DATE>2024-06-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="43" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="43" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
efi/capsule-loader: fix incorrect allocation size
|
|
|
|
gcc-14 notices that the allocation with sizeof(void) on 32-bit architectures
|
|
is not enough for a 64-bit phys_addr_t:
|
|
|
|
drivers/firmware/efi/capsule-loader.c: In function 'efi_capsule_open':
|
|
drivers/firmware/efi/capsule-loader.c:295:24: error: allocation of insufficient size '4' for type 'phys_addr_t' {aka 'long long unsigned int'} with size '8' [-Werror=alloc-size]
|
|
295 | cap_info->phys = kzalloc(sizeof(void *), GFP_KERNEL);
|
|
| ^
|
|
|
|
Use the correct type instead here.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2024-27413</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>High</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>7.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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="44" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="44" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netfilter: bridge: confirm multicast packets before passing them up the stack
|
|
|
|
conntrack nf_confirm logic cannot handle cloned skbs referencing
|
|
the same nf_conn entry, which will happen for multicast (broadcast)
|
|
frames on bridges.
|
|
|
|
Example:
|
|
macvlan0
|
|
|
|
|
br0
|
|
/ \
|
|
ethX ethY
|
|
|
|
ethX (or Y) receives a L2 multicast or broadcast packet containing
|
|
an IP packet, flow is not yet in conntrack table.
|
|
|
|
1. skb passes through bridge and fake-ip (br_netfilter)Prerouting.
|
|
-> skb->_nfct now references a unconfirmed entry
|
|
2. skb is broad/mcast packet. bridge now passes clones out on each bridge
|
|
interface.
|
|
3. skb gets passed up the stack.
|
|
4. In macvlan case, macvlan driver retains clone(s) of the mcast skb
|
|
and schedules a work queue to send them out on the lower devices.
|
|
|
|
The clone skb->_nfct is not a copy, it is the same entry as the
|
|
original skb. The macvlan rx handler then returns RX_HANDLER_PASS.
|
|
5. Normal conntrack hooks (in NF_INET_LOCAL_IN) confirm the orig skb.
|
|
|
|
The Macvlan broadcast worker and normal confirm path will race.
|
|
|
|
This race will not happen if step 2 already confirmed a clone. In that
|
|
case later steps perform skb_clone() with skb->_nfct already confirmed (in
|
|
hash table). This works fine.
|
|
|
|
But such confirmation won't happen when eb/ip/nftables rules dropped the
|
|
packets before they reached the nf_confirm step in postrouting.
|
|
|
|
Pablo points out that nf_conntrack_bridge doesn't allow use of stateful
|
|
nat, so we can safely discard the nf_conn entry and let inet call
|
|
conntrack again.
|
|
|
|
This doesn't work for bridge netfilter: skb could have a nat
|
|
transformation. Also bridge nf prevents re-invocation of inet prerouting
|
|
via 'sabotage_in' hook.
|
|
|
|
Work around this problem by explicit confirmation of the entry at LOCAL_IN
|
|
time, before upper layer has a chance to clone the unconfirmed entry.
|
|
|
|
The downside is that this disables NAT and conntrack helpers.
|
|
|
|
Alternative fix would be to add locking to all code parts that deal with
|
|
unconfirmed packets, but even if that could be done in a sane way this
|
|
opens up other problems, for example:
|
|
|
|
-m physdev --physdev-out eth0 -j SNAT --snat-to 1.2.3.4
|
|
-m physdev --physdev-out eth1 -j SNAT --snat-to 1.2.3.5
|
|
|
|
For multicast case, only one of such conflicting mappings will be
|
|
created, conntrack only handles 1:1 NAT mappings.
|
|
|
|
Users should set create a setup that explicitly marks such traffic
|
|
NOTRACK (conntrack bypass) to avoid this, but we cannot auto-bypass
|
|
them, ruleset might have accept rules for untracked traffic already,
|
|
so user-visible behaviour would change.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2024-27415</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="45" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="45" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: mac80211: check/clear fast rx for non-4addr sta VLAN changes
|
|
|
|
When moving a station out of a VLAN and deleting the VLAN afterwards, the
|
|
fast_rx entry still holds a pointer to the VLAN's netdev, which can cause
|
|
use-after-free bugs. Fix this by immediately calling ieee80211_check_fast_rx
|
|
after the VLAN change.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2024-35789</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>6.6</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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="46" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="46" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
md/dm-raid: don't call md_reap_sync_thread() directly
|
|
|
|
Currently md_reap_sync_thread() is called from raid_message() directly
|
|
without holding 'reconfig_mutex', this is definitely unsafe because
|
|
md_reap_sync_thread() can change many fields that is protected by
|
|
'reconfig_mutex'.
|
|
|
|
However, hold 'reconfig_mutex' here is still problematic because this
|
|
will cause deadlock, for example, commit 130443d60b1b ("md: refactor
|
|
idle/frozen_sync_thread() to fix deadlock").
|
|
|
|
Fix this problem by using stop_sync_thread() to unregister sync_thread,
|
|
like md/raid did.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2024-35808</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="47" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="47" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
usb: udc: remove warning when queue disabled ep
|
|
|
|
It is possible trigger below warning message from mass storage function,
|
|
|
|
WARNING: CPU: 6 PID: 3839 at drivers/usb/gadget/udc/core.c:294 usb_ep_queue+0x7c/0x104
|
|
pc : usb_ep_queue+0x7c/0x104
|
|
lr : fsg_main_thread+0x494/0x1b3c
|
|
|
|
Root cause is mass storage function try to queue request from main thread,
|
|
but other thread may already disable ep when function disable.
|
|
|
|
As there is no function failure in the driver, in order to avoid effort
|
|
to fix warning, change WARN_ON_ONCE() in usb_ep_queue() to pr_debug().</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2024-35822</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Low</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="48" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="48" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
vt: fix unicode buffer corruption when deleting characters
|
|
|
|
This is the same issue that was fixed for the VGA text buffer in commit
|
|
39cdb68c64d8 ("vt: fix memory overlapping when deleting chars in the
|
|
buffer"). The cure is also the same i.e. replace memcpy() with memmove()
|
|
due to the overlaping buffers.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2024-35823</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="49" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="49" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
mptcp: use OPTION_MPTCP_MPJ_SYNACK in subflow_finish_connect()
|
|
|
|
subflow_finish_connect() uses four fields (backup, join_id, thmac, none)
|
|
that may contain garbage unless OPTION_MPTCP_MPJ_SYNACK has been set
|
|
in mptcp_parse_option()</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2024-35840</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="50" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="50" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
mlxsw: spectrum_acl_tcam: Fix possible use-after-free during activity update
|
|
|
|
The rule activity update delayed work periodically traverses the list of
|
|
configured rules and queries their activity from the device.
|
|
|
|
As part of this task it accesses the entry pointed by 'ventry->entry',
|
|
but this entry can be changed concurrently by the rehash delayed work,
|
|
leading to a use-after-free [1].
|
|
|
|
Fix by closing the race and perform the activity query under the
|
|
'vregion->lock' mutex.
|
|
|
|
[1]
|
|
BUG: KASAN: slab-use-after-free in mlxsw_sp_acl_tcam_flower_rule_activity_get+0x121/0x140
|
|
Read of size 8 at addr ffff8881054ed808 by task kworker/0:18/181
|
|
|
|
CPU: 0 PID: 181 Comm: kworker/0:18 Not tainted 6.9.0-rc2-custom-00781-gd5ab772d32f7 #2
|
|
Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019
|
|
Workqueue: mlxsw_core mlxsw_sp_acl_rule_activity_update_work
|
|
Call Trace:
|
|
<TASK>
|
|
dump_stack_lvl+0xc6/0x120
|
|
print_report+0xce/0x670
|
|
kasan_report+0xd7/0x110
|
|
mlxsw_sp_acl_tcam_flower_rule_activity_get+0x121/0x140
|
|
mlxsw_sp_acl_rule_activity_update_work+0x219/0x400
|
|
process_one_work+0x8eb/0x19b0
|
|
worker_thread+0x6c9/0xf70
|
|
kthread+0x2c9/0x3b0
|
|
ret_from_fork+0x4d/0x80
|
|
ret_from_fork_asm+0x1a/0x30
|
|
</TASK>
|
|
|
|
Allocated by task 1039:
|
|
kasan_save_stack+0x33/0x60
|
|
kasan_save_track+0x14/0x30
|
|
__kasan_kmalloc+0x8f/0xa0
|
|
__kmalloc+0x19c/0x360
|
|
mlxsw_sp_acl_tcam_entry_create+0x7b/0x1f0
|
|
mlxsw_sp_acl_tcam_vchunk_migrate_all+0x30d/0xb50
|
|
mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300
|
|
process_one_work+0x8eb/0x19b0
|
|
worker_thread+0x6c9/0xf70
|
|
kthread+0x2c9/0x3b0
|
|
ret_from_fork+0x4d/0x80
|
|
ret_from_fork_asm+0x1a/0x30
|
|
|
|
Freed by task 1039:
|
|
kasan_save_stack+0x33/0x60
|
|
kasan_save_track+0x14/0x30
|
|
kasan_save_free_info+0x3b/0x60
|
|
poison_slab_object+0x102/0x170
|
|
__kasan_slab_free+0x14/0x30
|
|
kfree+0xc1/0x290
|
|
mlxsw_sp_acl_tcam_vchunk_migrate_all+0x3d7/0xb50
|
|
mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300
|
|
process_one_work+0x8eb/0x19b0
|
|
worker_thread+0x6c9/0xf70
|
|
kthread+0x2c9/0x3b0
|
|
ret_from_fork+0x4d/0x80
|
|
ret_from_fork_asm+0x1a/0x30</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2024-35855</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="51" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="51" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
x86/mm/pat: fix VM_PAT handling in COW mappings
|
|
|
|
PAT handling won't do the right thing in COW mappings: the first PTE (or,
|
|
in fact, all PTEs) can be replaced during write faults to point at anon
|
|
folios. Reliably recovering the correct PFN and cachemode using
|
|
follow_phys() from PTEs will not work in COW mappings.
|
|
|
|
Using follow_phys(), we might just get the address+protection of the anon
|
|
folio (which is very wrong), or fail on swap/nonswap entries, failing
|
|
follow_phys() and triggering a WARN_ON_ONCE() in untrack_pfn() and
|
|
track_pfn_copy(), not properly calling free_pfn_range().
|
|
|
|
In free_pfn_range(), we either wouldn't call memtype_free() or would call
|
|
it with the wrong range, possibly leaking memory.
|
|
|
|
To fix that, let's update follow_phys() to refuse returning anon folios,
|
|
and fallback to using the stored PFN inside vma->vm_pgoff for COW mappings
|
|
if we run into that.
|
|
|
|
We will now properly handle untrack_pfn() with COW mappings, where we
|
|
don't need the cachemode. We'll have to fail fork()->track_pfn_copy() if
|
|
the first page was replaced by an anon folio, though: we'd have to store
|
|
the cachemode in the VMA to make this work, likely growing the VMA size.
|
|
|
|
For now, lets keep it simple and let track_pfn_copy() just fail in that
|
|
case: it would have failed in the past with swap/nonswap entries already,
|
|
and it would have done the wrong thing with anon folios.
|
|
|
|
Simple reproducer to trigger the WARN_ON_ONCE() in untrack_pfn():
|
|
|
|
<--- C reproducer --->
|
|
#include <stdio.h>
|
|
#include <sys/mman.h>
|
|
#include <unistd.h>
|
|
#include <liburing.h>
|
|
|
|
int main(void)
|
|
{
|
|
struct io_uring_params p = {};
|
|
int ring_fd;
|
|
size_t size;
|
|
char *map;
|
|
|
|
ring_fd = io_uring_setup(1, &p);
|
|
if (ring_fd < 0) {
|
|
perror("io_uring_setup");
|
|
return 1;
|
|
}
|
|
size = p.sq_off.array + p.sq_entries * sizeof(unsigned);
|
|
|
|
/* Map the submission queue ring MAP_PRIVATE */
|
|
map = mmap(0, size, PROT_READ | PROT_WRITE, MAP_PRIVATE,
|
|
ring_fd, IORING_OFF_SQ_RING);
|
|
if (map == MAP_FAILED) {
|
|
perror("mmap");
|
|
return 1;
|
|
}
|
|
|
|
/* We have at least one page. Let's COW it. */
|
|
*map = 0;
|
|
pause();
|
|
return 0;
|
|
}
|
|
<--- C reproducer --->
|
|
|
|
On a system with 16 GiB RAM and swap configured:
|
|
# ./iouring &
|
|
# memhog 16G
|
|
# killall iouring
|
|
[ 301.552930] ------------[ cut here ]------------
|
|
[ 301.553285] WARNING: CPU: 7 PID: 1402 at arch/x86/mm/pat/memtype.c:1060 untrack_pfn+0xf4/0x100
|
|
[ 301.553989] Modules linked in: binfmt_misc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_g
|
|
[ 301.558232] CPU: 7 PID: 1402 Comm: iouring Not tainted 6.7.5-100.fc38.x86_64 #1
|
|
[ 301.558772] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebu4
|
|
[ 301.559569] RIP: 0010:untrack_pfn+0xf4/0x100
|
|
[ 301.559893] Code: 75 c4 eb cf 48 8b 43 10 8b a8 e8 00 00 00 3b 6b 28 74 b8 48 8b 7b 30 e8 ea 1a f7 000
|
|
[ 301.561189] RSP: 0018:ffffba2c0377fab8 EFLAGS: 00010282
|
|
[ 301.561590] RAX: 00000000ffffffea RBX: ffff9208c8ce9cc0 RCX: 000000010455e047
|
|
[ 301.562105] RDX: 07fffffff0eb1e0a RSI: 0000000000000000 RDI: ffff9208c391d200
|
|
[ 301.562628] RBP: 0000000000000000 R08: ffffba2c0377fab8 R09: 0000000000000000
|
|
[ 301.563145] R10: ffff9208d2292d50 R11: 0000000000000002 R12: 00007fea890e0000
|
|
[ 301.563669] R13: 0000000000000000 R14: ffffba2c0377fc08 R15: 0000000000000000
|
|
[ 301.564186] FS: 0000000000000000(0000) GS:ffff920c2fbc0000(0000) knlGS:0000000000000000
|
|
[ 301.564773] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ 301.565197] CR2: 00007fea88ee8a20 CR3: 00000001033a8000 CR4: 0000000000750ef0
|
|
[ 301.565725] PKRU: 55555554
|
|
[ 301.565944] Call Trace:
|
|
[ 301.566148] <TASK>
|
|
[ 301.566325] ? untrack_pfn+0xf4/0x100
|
|
[ 301.566618] ? __warn+0x81/0x130
|
|
[ 301.566876] ? untrack_pfn+0xf4/0x100
|
|
[ 3
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2024-35877</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="52" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="52" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
netfilter: nf_tables: reject new basechain after table flag update
|
|
|
|
When dormant flag is toggled, hooks are disabled in the commit phase by
|
|
iterating over current chains in table (existing and new).
|
|
|
|
The following configuration allows for an inconsistent state:
|
|
|
|
add table x
|
|
add chain x y { type filter hook input priority 0; }
|
|
add table x { flags dormant; }
|
|
add chain x w { type filter hook input priority 1; }
|
|
|
|
which triggers the following warning when trying to unregister chain w
|
|
which is already unregistered.
|
|
|
|
[ 127.322252] WARNING: CPU: 7 PID: 1211 at net/netfilter/core.c:50 1 __nf_unregister_net_hook+0x21a/0x260
|
|
[...]
|
|
[ 127.322519] Call Trace:
|
|
[ 127.322521] <TASK>
|
|
[ 127.322524] ? __warn+0x9f/0x1a0
|
|
[ 127.322531] ? __nf_unregister_net_hook+0x21a/0x260
|
|
[ 127.322537] ? report_bug+0x1b1/0x1e0
|
|
[ 127.322545] ? handle_bug+0x3c/0x70
|
|
[ 127.322552] ? exc_invalid_op+0x17/0x40
|
|
[ 127.322556] ? asm_exc_invalid_op+0x1a/0x20
|
|
[ 127.322563] ? kasan_save_free_info+0x3b/0x60
|
|
[ 127.322570] ? __nf_unregister_net_hook+0x6a/0x260
|
|
[ 127.322577] ? __nf_unregister_net_hook+0x21a/0x260
|
|
[ 127.322583] ? __nf_unregister_net_hook+0x6a/0x260
|
|
[ 127.322590] ? __nf_tables_unregister_hook+0x8a/0xe0 [nf_tables]
|
|
[ 127.322655] nft_table_disable+0x75/0xf0 [nf_tables]
|
|
[ 127.322717] nf_tables_commit+0x2571/0x2620 [nf_tables]</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2024-35900</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="53" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="53" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
selinux: avoid dereference of garbage after mount failure
|
|
|
|
In case kern_mount() fails and returns an error pointer return in the
|
|
error branch instead of continuing and dereferencing the error pointer.
|
|
|
|
While on it drop the never read static variable selinuxfs_mount.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2024-35904</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="54" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="54" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
block: prevent division by zero in blk_rq_stat_sum()
|
|
|
|
The expression dst->nr_samples + src->nr_samples may
|
|
have zero value on overflow. It is necessary to add
|
|
a check to avoid division by zero.
|
|
|
|
Found by Linux Verification Center (linuxtesting.org) with Svace.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2024-35925</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="55" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="55" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
dma-direct: Leak pages on dma_set_decrypted() failure
|
|
|
|
On TDX it is possible for the untrusted host to cause
|
|
set_memory_encrypted() or set_memory_decrypted() to fail such that an
|
|
error is returned and the resulting memory is shared. Callers need to
|
|
take care to handle these errors to avoid returning decrypted (shared)
|
|
memory to the page allocator, which could lead to functional or security
|
|
issues.
|
|
|
|
DMA could free decrypted/shared pages if dma_set_decrypted() fails. This
|
|
should be a rare case. Just leak the pages in this case instead of
|
|
freeing them.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2024-35939</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="56" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="56" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
drm/client: Fully protect modes[] with dev->mode_config.mutex
|
|
|
|
The modes[] array contains pointers to modes on the connectors'
|
|
mode lists, which are protected by dev->mode_config.mutex.
|
|
Thus we need to extend modes[] the same protection or by the
|
|
time we use it the elements may already be pointing to
|
|
freed/reused memory.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2024-35950</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>High</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>7.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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="57" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="57" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
btrfs: qgroup: fix qgroup prealloc rsv leak in subvolume operations
|
|
|
|
Create subvolume, create snapshot and delete subvolume all use
|
|
btrfs_subvolume_reserve_metadata() to reserve metadata for the changes
|
|
done to the parent subvolume's fs tree, which cannot be mediated in the
|
|
normal way via start_transaction. When quota groups (squota or qgroups)
|
|
are enabled, this reserves qgroup metadata of type PREALLOC. Once the
|
|
operation is associated to a transaction, we convert PREALLOC to
|
|
PERTRANS, which gets cleared in bulk at the end of the transaction.
|
|
|
|
However, the error paths of these three operations were not implementing
|
|
this lifecycle correctly. They unconditionally converted the PREALLOC to
|
|
PERTRANS in a generic cleanup step regardless of errors or whether the
|
|
operation was fully associated to a transaction or not. This resulted in
|
|
error paths occasionally converting this rsv to PERTRANS without calling
|
|
record_root_in_trans successfully, which meant that unless that root got
|
|
recorded in the transaction by some other thread, the end of the
|
|
transaction would not free that root's PERTRANS, leaking it. Ultimately,
|
|
this resulted in hitting a WARN in CONFIG_BTRFS_DEBUG builds at unmount
|
|
for the leaked reservation.
|
|
|
|
The fix is to ensure that every qgroup PREALLOC reservation observes the
|
|
following properties:
|
|
|
|
1. any failure before record_root_in_trans is called successfully
|
|
results in freeing the PREALLOC reservation.
|
|
2. after record_root_in_trans, we convert to PERTRANS, and now the
|
|
transaction owns freeing the reservation.
|
|
|
|
This patch enforces those properties on the three operations. Without
|
|
it, generic/269 with squotas enabled at mkfs time would fail in ~5-10
|
|
runs on my system. With this patch, it ran successfully 1000 times in a
|
|
row.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2024-35956</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="58" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="58" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net: ena: Fix incorrect descriptor free behavior
|
|
|
|
ENA has two types of TX queues:
|
|
- queues which only process TX packets arriving from the network stack
|
|
- queues which only process TX packets forwarded to it by XDP_REDIRECT
|
|
or XDP_TX instructions
|
|
|
|
The ena_free_tx_bufs() cycles through all descriptors in a TX queue
|
|
and unmaps + frees every descriptor that hasn't been acknowledged yet
|
|
by the device (uncompleted TX transactions).
|
|
The function assumes that the processed TX queue is necessarily from
|
|
the first category listed above and ends up using napi_consume_skb()
|
|
for descriptors belonging to an XDP specific queue.
|
|
|
|
This patch solves a bug in which, in case of a VF reset, the
|
|
descriptors aren't freed correctly, leading to crashes.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2024-35958</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="59" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="59" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
net/mlx5: Properly link new fs rules into the tree
|
|
|
|
Previously, add_rule_fg would only add newly created rules from the
|
|
handle into the tree when they had a refcount of 1. On the other hand,
|
|
create_flow_handle tries hard to find and reference already existing
|
|
identical rules instead of creating new ones.
|
|
|
|
These two behaviors can result in a situation where create_flow_handle
|
|
1) creates a new rule and references it, then
|
|
2) in a subsequent step during the same handle creation references it
|
|
again,
|
|
resulting in a rule with a refcount of 2 that is not linked into the
|
|
tree, will have a NULL parent and root and will result in a crash when
|
|
the flow group is deleted because del_sw_hw_rule, invoked on rule
|
|
deletion, assumes node->parent is != NULL.
|
|
|
|
This happened in the wild, due to another bug related to incorrect
|
|
handling of duplicate pkt_reformat ids, which lead to the code in
|
|
create_flow_handle incorrectly referencing a just-added rule in the same
|
|
flow handle, resulting in the problem described above. Full details are
|
|
at [1].
|
|
|
|
This patch changes add_rule_fg to add new rules without parents into
|
|
the tree, properly initializing them and avoiding the crash. This makes
|
|
it more consistent with how rules are added to an FTE in
|
|
create_flow_handle.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2024-35960</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="60" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="60" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:Bluetooth: Fix memory leak in hci_req_sync_complete()In hci_req_sync_complete() , always free the previous syncrequest state before assigning reference to a new one.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2024-35978</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="61" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="61" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
dmaengine: idxd: Fix oops during rmmod on single-CPU platforms
|
|
|
|
During the removal of the idxd driver, registered offline callback is
|
|
invoked as part of the clean up process. However, on systems with only
|
|
one CPU online, no valid target is available to migrate the
|
|
perf context, resulting in a kernel oops:
|
|
|
|
BUG: unable to handle page fault for address: 000000000002a2b8
|
|
#PF: supervisor write access in kernel mode
|
|
#PF: error_code(0x0002) - not-present page
|
|
PGD 1470e1067 P4D 0
|
|
Oops: 0002 [#1] PREEMPT SMP NOPTI
|
|
CPU: 0 PID: 20 Comm: cpuhp/0 Not tainted 6.8.0-rc6-dsa+ #57
|
|
Hardware name: Intel Corporation AvenueCity/AvenueCity, BIOS BHSDCRB1.86B.2492.D03.2307181620 07/18/2023
|
|
RIP: 0010:mutex_lock+0x2e/0x50
|
|
...
|
|
Call Trace:
|
|
<TASK>
|
|
__die+0x24/0x70
|
|
page_fault_oops+0x82/0x160
|
|
do_user_addr_fault+0x65/0x6b0
|
|
__pfx___rdmsr_safe_on_cpu+0x10/0x10
|
|
exc_page_fault+0x7d/0x170
|
|
asm_exc_page_fault+0x26/0x30
|
|
mutex_lock+0x2e/0x50
|
|
mutex_lock+0x1e/0x50
|
|
perf_pmu_migrate_context+0x87/0x1f0
|
|
perf_event_cpu_offline+0x76/0x90 [idxd]
|
|
cpuhp_invoke_callback+0xa2/0x4f0
|
|
__pfx_perf_event_cpu_offline+0x10/0x10 [idxd]
|
|
cpuhp_thread_fun+0x98/0x150
|
|
smpboot_thread_fn+0x27/0x260
|
|
smpboot_thread_fn+0x1af/0x260
|
|
__pfx_smpboot_thread_fn+0x10/0x10
|
|
kthread+0x103/0x140
|
|
__pfx_kthread+0x10/0x10
|
|
ret_from_fork+0x31/0x50
|
|
__pfx_kthread+0x10/0x10
|
|
ret_from_fork_asm+0x1b/0x30
|
|
<TASK>
|
|
|
|
Fix the issue by preventing the migration of the perf context to an
|
|
invalid target.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2024-35989</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="62" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="62" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
mm/hugetlb: fix missing hugetlb_lock for resv uncharge
|
|
|
|
There is a recent report on UFFDIO_COPY over hugetlb:
|
|
|
|
https://lore.kernel.org/all/000000000000ee06de0616177560@google.com/
|
|
|
|
350: lockdep_assert_held(&hugetlb_lock);
|
|
|
|
Should be an issue in hugetlb but triggered in an userfault context, where
|
|
it goes into the unlikely path where two threads modifying the resv map
|
|
together. Mike has a fix in that path for resv uncharge but it looks like
|
|
the locking criteria was overlooked: hugetlb_cgroup_uncharge_folio_rsvd()
|
|
will update the cgroup pointer, so it requires to be called with the lock
|
|
held.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2024-36000</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="63" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="63" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
i40e: Do not use WQ_MEM_RECLAIM flag for workqueue
|
|
|
|
Issue reported by customer during SRIOV testing, call trace:
|
|
When both i40e and the i40iw driver are loaded, a warning
|
|
in check_flush_dependency is being triggered. This seems
|
|
to be because of the i40e driver workqueue is allocated with
|
|
the WQ_MEM_RECLAIM flag, and the i40iw one is not.
|
|
|
|
Similar error was encountered on ice too and it was fixed by
|
|
removing the flag. Do the same for i40e too.
|
|
|
|
[Feb 9 09:08] ------------[ cut here ]------------
|
|
[ +0.000004] workqueue: WQ_MEM_RECLAIM i40e:i40e_service_task [i40e] is
|
|
flushing !WQ_MEM_RECLAIM infiniband:0x0
|
|
[ +0.000060] WARNING: CPU: 0 PID: 937 at kernel/workqueue.c:2966
|
|
check_flush_dependency+0x10b/0x120
|
|
[ +0.000007] Modules linked in: snd_seq_dummy snd_hrtimer snd_seq
|
|
snd_timer snd_seq_device snd soundcore nls_utf8 cifs cifs_arc4
|
|
nls_ucs2_utils rdma_cm iw_cm ib_cm cifs_md4 dns_resolver netfs qrtr
|
|
rfkill sunrpc vfat fat intel_rapl_msr intel_rapl_common irdma
|
|
intel_uncore_frequency intel_uncore_frequency_common ice ipmi_ssif
|
|
isst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermal
|
|
intel_powerclamp gnss coretemp ib_uverbs rapl intel_cstate ib_core
|
|
iTCO_wdt iTCO_vendor_support acpi_ipmi mei_me ipmi_si intel_uncore
|
|
ioatdma i2c_i801 joydev pcspkr mei ipmi_devintf lpc_ich
|
|
intel_pch_thermal i2c_smbus ipmi_msghandler acpi_power_meter acpi_pad
|
|
xfs libcrc32c ast sd_mod drm_shmem_helper t10_pi drm_kms_helper sg ixgbe
|
|
drm i40e ahci crct10dif_pclmul libahci crc32_pclmul igb crc32c_intel
|
|
libata ghash_clmulni_intel i2c_algo_bit mdio dca wmi dm_mirror
|
|
dm_region_hash dm_log dm_mod fuse
|
|
[ +0.000050] CPU: 0 PID: 937 Comm: kworker/0:3 Kdump: loaded Not
|
|
tainted 6.8.0-rc2-Feb-net_dev-Qiueue-00279-gbd43c5687e05 #1
|
|
[ +0.000003] Hardware name: Intel Corporation S2600BPB/S2600BPB, BIOS
|
|
SE5C620.86B.02.01.0013.121520200651 12/15/2020
|
|
[ +0.000001] Workqueue: i40e i40e_service_task [i40e]
|
|
[ +0.000024] RIP: 0010:check_flush_dependency+0x10b/0x120
|
|
[ +0.000003] Code: ff 49 8b 54 24 18 48 8d 8b b0 00 00 00 49 89 e8 48
|
|
81 c6 b0 00 00 00 48 c7 c7 b0 97 fa 9f c6 05 8a cc 1f 02 01 e8 35 b3 fd
|
|
ff <0f> 0b e9 10 ff ff ff 80 3d 78 cc 1f 02 00 75 94 e9 46 ff ff ff 90
|
|
[ +0.000002] RSP: 0018:ffffbd294976bcf8 EFLAGS: 00010282
|
|
[ +0.000002] RAX: 0000000000000000 RBX: ffff94d4c483c000 RCX:
|
|
0000000000000027
|
|
[ +0.000001] RDX: ffff94d47f620bc8 RSI: 0000000000000001 RDI:
|
|
ffff94d47f620bc0
|
|
[ +0.000001] RBP: 0000000000000000 R08: 0000000000000000 R09:
|
|
00000000ffff7fff
|
|
[ +0.000001] R10: ffffbd294976bb98 R11: ffffffffa0be65e8 R12:
|
|
ffff94c5451ea180
|
|
[ +0.000001] R13: ffff94c5ab5e8000 R14: ffff94c5c20b6e05 R15:
|
|
ffff94c5f1330ab0
|
|
[ +0.000001] FS: 0000000000000000(0000) GS:ffff94d47f600000(0000)
|
|
knlGS:0000000000000000
|
|
[ +0.000002] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
|
|
[ +0.000001] CR2: 00007f9e6f1fca70 CR3: 0000000038e20004 CR4:
|
|
00000000007706f0
|
|
[ +0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
|
|
0000000000000000
|
|
[ +0.000001] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
|
|
0000000000000400
|
|
[ +0.000001] PKRU: 55555554
|
|
[ +0.000001] Call Trace:
|
|
[ +0.000001] <TASK>
|
|
[ +0.000002] ? __warn+0x80/0x130
|
|
[ +0.000003] ? check_flush_dependency+0x10b/0x120
|
|
[ +0.000002] ? report_bug+0x195/0x1a0
|
|
[ +0.000005] ? handle_bug+0x3c/0x70
|
|
[ +0.000003] ? exc_invalid_op+0x14/0x70
|
|
[ +0.000002] ? asm_exc_invalid_op+0x16/0x20
|
|
[ +0.000006] ? check_flush_dependency+0x10b/0x120
|
|
[ +0.000002] ? check_flush_dependency+0x10b/0x120
|
|
[ +0.000002] __flush_workqueue+0x126/0x3f0
|
|
[ +0.000015] ib_cache_cleanup_one+0x1c/0xe0 [ib_core]
|
|
[ +0.000056] __ib_unregister_device+0x6a/0xb0 [ib_core]
|
|
[ +0.000023] ib_unregister_device_and_put+0x34/0x50 [ib_core]
|
|
[ +0.000020] i40iw_close+0x4b/0x90 [irdma]
|
|
[ +0.000022] i40e_notify_client_of_netdev_close+0x54/0xc0 [i40e]
|
|
[ +0.000035] i40e_service_task+0x126/0x190 [i40e]
|
|
[ +0.000024] process_one_work+0x174/0x340
|
|
[ +0.000003] worker_th
|
|
---truncated---</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2024-36004</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="64" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="64" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
mlxsw: spectrum_acl_tcam: Fix warning during rehash
|
|
|
|
As previously explained, the rehash delayed work migrates filters from
|
|
one region to another. This is done by iterating over all chunks (all
|
|
the filters with the same priority) in the region and in each chunk
|
|
iterating over all the filters.
|
|
|
|
When the work runs out of credits it stores the current chunk and entry
|
|
as markers in the per-work context so that it would know where to resume
|
|
the migration from the next time the work is scheduled.
|
|
|
|
Upon error, the chunk marker is reset to NULL, but without resetting the
|
|
entry markers despite being relative to it. This can result in migration
|
|
being resumed from an entry that does not belong to the chunk being
|
|
migrated. In turn, this will eventually lead to a chunk being iterated
|
|
over as if it is an entry. Because of how the two structures happen to
|
|
be defined, this does not lead to KASAN splats, but to warnings such as
|
|
[1].
|
|
|
|
Fix by creating a helper that resets all the markers and call it from
|
|
all the places the currently only reset the chunk marker. For good
|
|
measures also call it when starting a completely new rehash. Add a
|
|
warning to avoid future cases.
|
|
|
|
[1]
|
|
WARNING: CPU: 7 PID: 1076 at drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_keys.c:407 mlxsw_afk_encode+0x242/0x2f0
|
|
Modules linked in:
|
|
CPU: 7 PID: 1076 Comm: kworker/7:24 Tainted: G W 6.9.0-rc3-custom-00880-g29e61d91b77b #29
|
|
Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019
|
|
Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work
|
|
RIP: 0010:mlxsw_afk_encode+0x242/0x2f0
|
|
[...]
|
|
Call Trace:
|
|
<TASK>
|
|
mlxsw_sp_acl_atcam_entry_add+0xd9/0x3c0
|
|
mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0
|
|
mlxsw_sp_acl_tcam_vchunk_migrate_all+0x109/0x290
|
|
mlxsw_sp_acl_tcam_vregion_rehash_work+0x6c/0x470
|
|
process_one_work+0x151/0x370
|
|
worker_thread+0x2cb/0x3e0
|
|
kthread+0xd0/0x100
|
|
ret_from_fork+0x34/0x50
|
|
</TASK></Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2024-36007</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="65" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="65" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ppdev: Add an error check in register_device
|
|
|
|
In register_device, the return value of ida_simple_get is unchecked,
|
|
in witch ida_simple_get will use an invalid index value.
|
|
|
|
To address this issue, index should be checked after ida_simple_get. When
|
|
the index value is abnormal, a warning message should be printed, the port
|
|
should be dropped, and the value should be recorded.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2024-36015</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="66" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="66" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
pinctrl: core: delete incorrect free in pinctrl_enable()
|
|
|
|
The "pctldev" struct is allocated in devm_pinctrl_register_and_init().
|
|
It's a devm_ managed pointer that is freed by devm_pinctrl_dev_release(),
|
|
so freeing it in pinctrl_enable() will lead to a double free.
|
|
|
|
The devm_pinctrl_dev_release() function frees the pindescs and destroys
|
|
the mutex as well.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2024-36940</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP3</ProductID>
|
|
</Status>
|
|
</ProductStatuses>
|
|
<Threats>
|
|
<Threat Type="Impact">
|
|
<Description>Medium</Description>
|
|
</Threat>
|
|
</Threats>
|
|
<CVSSScoreSets>
|
|
<ScoreSet>
|
|
<BaseScore>5.5</BaseScore>
|
|
<Vector>AV:L/AC: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-07</DATE>
|
|
<URL>https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1694</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
</cvrfdoc> |