4096 lines
175 KiB
XML
4096 lines
175 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-SP1</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-1693</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-SP1.</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:
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
usb: aqc111: check packet for fixup for true limit
|
|
|
|
If a device sends a packet that is inbetween 0
|
|
and sizeof(u64) the value passed to skb_trim()
|
|
as length will wrap around ending up as some very
|
|
large value.
|
|
|
|
The driver will then proceed to parse the header
|
|
located at that position, which will either oops or
|
|
process some random value.
|
|
|
|
The fix is to check against sizeof(u64) rather than
|
|
0, which the driver currently does. The issue exists
|
|
since the introduction of the driver.(CVE-2023-52655)
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
net/usb: kalmia: Don't pass act_len in usb_bulk_msg error path
|
|
|
|
syzbot reported that act_len in kalmia_send_init_packet() is
|
|
uninitialized when passing it to the first usb_bulk_msg error path. Jiri
|
|
Pirko noted that it's pointless to pass it in the error path, and that
|
|
the value that would be printed in the second error path would be the
|
|
value of act_len from the first call to usb_bulk_msg.[1]
|
|
|
|
With this in mind, let's just not pass act_len to the usb_bulk_msg error
|
|
paths.
|
|
|
|
1: https://lore.kernel.org/lkml/Y9pY61y1nwTuzMOa@nanopsycho/(CVE-2023-52703)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
mmc: sdio: fix possible resource leaks in some error paths
|
|
|
|
If sdio_add_func() or sdio_init_func() fails, sdio_remove_func() can
|
|
not release the resources, because the sdio function is not presented
|
|
in these two cases, it won't call of_node_put() or put_device().
|
|
|
|
To fix these leaks, make sdio_func_present() only control whether
|
|
device_del() needs to be called or not, then always call of_node_put()
|
|
and put_device().
|
|
|
|
In error case in sdio_init_func(), the reference of 'card->dev' is
|
|
not get, to avoid redundant put in sdio_free_func_cis(), move the
|
|
get_device() to sdio_alloc_func() and put_device() to sdio_release_func(),
|
|
it can keep the get/put function be balanced.
|
|
|
|
Without this patch, while doing fault inject test, it can get the
|
|
following leak reports, after this fix, the leak is gone.
|
|
|
|
unreferenced object 0xffff888112514000 (size 2048):
|
|
comm "kworker/3:2", pid 65, jiffies 4294741614 (age 124.774s)
|
|
hex dump (first 32 bytes):
|
|
00 e0 6f 12 81 88 ff ff 60 58 8d 06 81 88 ff ff ..o.....`X......
|
|
10 40 51 12 81 88 ff ff 10 40 51 12 81 88 ff ff .@Q......@Q.....
|
|
backtrace:
|
|
[<000000009e5931da>] kmalloc_trace+0x21/0x110
|
|
[<000000002f839ccb>] mmc_alloc_card+0x38/0xb0 [mmc_core]
|
|
[<0000000004adcbf6>] mmc_sdio_init_card+0xde/0x170 [mmc_core]
|
|
[<000000007538fea0>] mmc_attach_sdio+0xcb/0x1b0 [mmc_core]
|
|
[<00000000d4fdeba7>] mmc_rescan+0x54a/0x640 [mmc_core]
|
|
|
|
unreferenced object 0xffff888112511000 (size 2048):
|
|
comm "kworker/3:2", pid 65, jiffies 4294741623 (age 124.766s)
|
|
hex dump (first 32 bytes):
|
|
00 40 51 12 81 88 ff ff e0 58 8d 06 81 88 ff ff .@Q......X......
|
|
10 10 51 12 81 88 ff ff 10 10 51 12 81 88 ff ff ..Q.......Q.....
|
|
backtrace:
|
|
[<000000009e5931da>] kmalloc_trace+0x21/0x110
|
|
[<00000000fcbe706c>] sdio_alloc_func+0x35/0x100 [mmc_core]
|
|
[<00000000c68f4b50>] mmc_attach_sdio.cold.18+0xb1/0x395 [mmc_core]
|
|
[<00000000d4fdeba7>] mmc_rescan+0x54a/0x640 [mmc_core](CVE-2023-52730)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
bpf, sockmap: Don't let sock_map_{close,destroy,unhash} call itself
|
|
|
|
sock_map proto callbacks should never call themselves by design. Protect
|
|
against bugs like [1] and break out of the recursive loop to avoid a stack
|
|
overflow in favor of a resource leak.
|
|
|
|
[1] https://lore.kernel.org/all/00000000000073b14905ef2e7401@google.com/(CVE-2023-52735)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ALSA: hda: Do not unset preset when cleaning up codec
|
|
|
|
Several functions that take part in codec's initialization and removal
|
|
are re-used by ASoC codec drivers implementations. Drivers mimic the
|
|
behavior of hda_codec_driver_probe/remove() found in
|
|
sound/pci/hda/hda_bind.c with their component->probe/remove() instead.
|
|
|
|
One of the reasons for that is the expectation of
|
|
snd_hda_codec_device_new() to receive a valid pointer to an instance of
|
|
struct snd_card. This expectation can be met only once sound card
|
|
components probing commences.
|
|
|
|
As ASoC sound card may be unbound without codec device being actually
|
|
removed from the system, unsetting ->preset in
|
|
snd_hda_codec_cleanup_for_unbind() interferes with module unload -> load
|
|
scenario causing null-ptr-deref. Preset is assigned only once, during
|
|
device/driver matching whereas ASoC codec driver's module reloading may
|
|
occur several times throughout the lifetime of an audio stack.(CVE-2023-52736)
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
fs/jfs: Add validity check for db_maxag and db_agpref
|
|
|
|
Both db_maxag and db_agpref are used as the index of the
|
|
db_agfree array, but there is currently no validity check for
|
|
db_maxag and db_agpref, which can lead to errors.
|
|
|
|
The following is related bug reported by Syzbot:
|
|
|
|
UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:639:20
|
|
index 7936 is out of range for type 'atomic_t[128]'
|
|
|
|
Add checking that the values of db_maxag and db_agpref are valid
|
|
indexes for the db_agfree array.(CVE-2023-52804)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
jfs: fix array-index-out-of-bounds in diAlloc
|
|
|
|
Currently there is not check against the agno of the iag while
|
|
allocating new inodes to avoid fragmentation problem. Added the check
|
|
which is required.(CVE-2023-52805)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
scsi: hisi_sas: Set debugfs_dir pointer to NULL after removing debugfs
|
|
|
|
If init debugfs failed during device registration due to memory allocation
|
|
failure, debugfs_remove_recursive() is called, after which debugfs_dir is
|
|
not set to NULL. debugfs_remove_recursive() will be called again during
|
|
device removal. As a result, illegal pointer is accessed.
|
|
|
|
[ 1665.467244] hisi_sas_v3_hw 0000:b4:02.0: failed to init debugfs!
|
|
...
|
|
[ 1669.836708] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0
|
|
[ 1669.872669] pc : down_write+0x24/0x70
|
|
[ 1669.876315] lr : down_write+0x1c/0x70
|
|
[ 1669.879961] sp : ffff000036f53a30
|
|
[ 1669.883260] x29: ffff000036f53a30 x28: ffffa027c31549f8
|
|
[ 1669.888547] x27: ffffa027c3140000 x26: 0000000000000000
|
|
[ 1669.893834] x25: ffffa027bf37c270 x24: ffffa027bf37c270
|
|
[ 1669.899122] x23: ffff0000095406b8 x22: ffff0000095406a8
|
|
[ 1669.904408] x21: 0000000000000000 x20: ffffa027bf37c310
|
|
[ 1669.909695] x19: 00000000000000a0 x18: ffff8027dcd86f10
|
|
[ 1669.914982] x17: 0000000000000000 x16: 0000000000000000
|
|
[ 1669.920268] x15: 0000000000000000 x14: ffffa0274014f870
|
|
[ 1669.925555] x13: 0000000000000040 x12: 0000000000000228
|
|
[ 1669.930842] x11: 0000000000000020 x10: 0000000000000bb0
|
|
[ 1669.936129] x9 : ffff000036f537f0 x8 : ffff80273088ca10
|
|
[ 1669.941416] x7 : 000000000000001d x6 : 00000000ffffffff
|
|
[ 1669.946702] x5 : ffff000008a36310 x4 : ffff80273088be00
|
|
[ 1669.951989] x3 : ffff000009513e90 x2 : 0000000000000000
|
|
[ 1669.957276] x1 : 00000000000000a0 x0 : ffffffff00000001
|
|
[ 1669.962563] Call trace:
|
|
[ 1669.965000] down_write+0x24/0x70
|
|
[ 1669.968301] debugfs_remove_recursive+0x5c/0x1b0
|
|
[ 1669.972905] hisi_sas_debugfs_exit+0x24/0x30 [hisi_sas_main]
|
|
[ 1669.978541] hisi_sas_v3_remove+0x130/0x150 [hisi_sas_v3_hw]
|
|
[ 1669.984175] pci_device_remove+0x48/0xd8
|
|
[ 1669.988082] device_release_driver_internal+0x1b4/0x250
|
|
[ 1669.993282] device_release_driver+0x28/0x38
|
|
[ 1669.997534] pci_stop_bus_device+0x84/0xb8
|
|
[ 1670.001611] pci_stop_and_remove_bus_device_locked+0x24/0x40
|
|
[ 1670.007244] remove_store+0xfc/0x140
|
|
[ 1670.010802] dev_attr_store+0x44/0x60
|
|
[ 1670.014448] sysfs_kf_write+0x58/0x80
|
|
[ 1670.018095] kernfs_fop_write+0xe8/0x1f0
|
|
[ 1670.022000] __vfs_write+0x60/0x190
|
|
[ 1670.025472] vfs_write+0xac/0x1c0
|
|
[ 1670.028771] ksys_write+0x6c/0xd8
|
|
[ 1670.032071] __arm64_sys_write+0x24/0x30
|
|
[ 1670.035977] el0_svc_common+0x78/0x130
|
|
[ 1670.039710] el0_svc_handler+0x38/0x78
|
|
[ 1670.043442] el0_svc+0x8/0xc
|
|
|
|
To fix this, set debugfs_dir to NULL after debugfs_remove_recursive().(CVE-2023-52808)
|
|
|
|
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 SMU7
|
|
|
|
For pptable structs that use flexible array sizes, use flexible arrays.(CVE-2023-52818)
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
tipc: Change nla_policy for bearer-related names to NLA_NUL_STRING
|
|
|
|
syzbot reported the following uninit-value access issue [1]:
|
|
|
|
=====================================================
|
|
BUG: KMSAN: uninit-value in strlen lib/string.c:418 [inline]
|
|
BUG: KMSAN: uninit-value in strstr+0xb8/0x2f0 lib/string.c:756
|
|
strlen lib/string.c:418 [inline]
|
|
strstr+0xb8/0x2f0 lib/string.c:756
|
|
tipc_nl_node_reset_link_stats+0x3ea/0xb50 net/tipc/node.c:2595
|
|
genl_family_rcv_msg_doit net/netlink/genetlink.c:971 [inline]
|
|
genl_family_rcv_msg net/netlink/genetlink.c:1051 [inline]
|
|
genl_rcv_msg+0x11ec/0x1290 net/netlink/genetlink.c:1066
|
|
netlink_rcv_skb+0x371/0x650 net/netlink/af_netlink.c:2545
|
|
genl_rcv+0x40/0x60 net/netlink/genetlink.c:1075
|
|
netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline]
|
|
netlink_unicast+0xf47/0x1250 net/netlink/af_netlink.c:1368
|
|
netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
sock_sendmsg net/socket.c:753 [inline]
|
|
____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541
|
|
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595
|
|
__sys_sendmsg net/socket.c:2624 [inline]
|
|
__do_sys_sendmsg net/socket.c:2633 [inline]
|
|
__se_sys_sendmsg net/socket.c:2631 [inline]
|
|
__x64_sys_sendmsg+0x307/0x490 net/socket.c:2631
|
|
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
|
|
do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
|
|
entry_SYSCALL_64_after_hwframe+0x63/0xcd
|
|
|
|
Uninit was created at:
|
|
slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767
|
|
slab_alloc_node mm/slub.c:3478 [inline]
|
|
kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523
|
|
kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:559
|
|
__alloc_skb+0x318/0x740 net/core/skbuff.c:650
|
|
alloc_skb include/linux/skbuff.h:1286 [inline]
|
|
netlink_alloc_large_skb net/netlink/af_netlink.c:1214 [inline]
|
|
netlink_sendmsg+0xb34/0x13d0 net/netlink/af_netlink.c:1885
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
sock_sendmsg net/socket.c:753 [inline]
|
|
____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541
|
|
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595
|
|
__sys_sendmsg net/socket.c:2624 [inline]
|
|
__do_sys_sendmsg net/socket.c:2633 [inline]
|
|
__se_sys_sendmsg net/socket.c:2631 [inline]
|
|
__x64_sys_sendmsg+0x307/0x490 net/socket.c:2631
|
|
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
|
|
do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
|
|
entry_SYSCALL_64_after_hwframe+0x63/0xcd
|
|
|
|
TIPC bearer-related names including link names must be null-terminated
|
|
strings. If a link name which is not null-terminated is passed through
|
|
netlink, strstr() and similar functions can cause buffer overrun. This
|
|
causes the above issue.
|
|
|
|
This patch changes the nla_policy for bearer-related names from NLA_STRING
|
|
to NLA_NUL_STRING. This resolves the issue by ensuring that only
|
|
null-terminated strings are accepted as bearer-related names.
|
|
|
|
syzbot reported similar uninit-value issue related to bearer names [2]. The
|
|
root cause of this issue is that a non-null-terminated bearer name was
|
|
passed. This patch also resolved this issue.(CVE-2023-52845)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
clk: mediatek: clk-mt7629: 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-52858)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
perf: hisi: Fix use-after-free when register pmu fails
|
|
|
|
When we fail to register the uncore pmu, the pmu context may not been
|
|
allocated. The error handing will call cpuhp_state_remove_instance()
|
|
to call uncore pmu offline callback, which migrate the pmu context.
|
|
Since that's liable to lead to some kind of use-after-free.
|
|
|
|
Use cpuhp_state_remove_instance_nocalls() instead of
|
|
cpuhp_state_remove_instance() so that the notifiers don't execute after
|
|
the PMU device has been failed to register.(CVE-2023-52859)
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
i2c: smbus: fix NULL function pointer dereference
|
|
|
|
Baruch reported an OOPS when using the designware controller as target
|
|
only. Target-only modes break the assumption of one transfer function
|
|
always being available. Fix this by always checking the pointer in
|
|
__i2c_transfer.
|
|
|
|
[wsa: dropped the simplification in core-smbus to avoid theoretical regressions](CVE-2024-35984)
|
|
|
|
In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
ACPI: CPPC: Use access_width over bit_width for system memory accesses
|
|
|
|
To align with ACPI 6.3+, since bit_width can be any 8-bit value, it
|
|
cannot be depended on to be always on a clean 8b boundary. This was
|
|
uncovered on the Cobalt 100 platform.
|
|
|
|
SError Interrupt on CPU26, code 0xbe000011 -- SError
|
|
CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted 5.15.2.1-13 #1
|
|
Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION
|
|
pstate: 62400009 (nZCv daif +PAN -UAO +TCO -DIT -SSBS BTYPE=--)
|
|
pc : cppc_get_perf_caps+0xec/0x410
|
|
lr : cppc_get_perf_caps+0xe8/0x410
|
|
sp : ffff8000155ab730
|
|
x29: ffff8000155ab730 x28: ffff0080139d0038 x27: ffff0080139d0078
|
|
x26: 0000000000000000 x25: ffff0080139d0058 x24: 00000000ffffffff
|
|
x23: ffff0080139d0298 x22: ffff0080139d0278 x21: 0000000000000000
|
|
x20: ffff00802b251910 x19: ffff0080139d0000 x18: ffffffffffffffff
|
|
x17: 0000000000000000 x16: ffffdc7e111bad04 x15: ffff00802b251008
|
|
x14: ffffffffffffffff x13: ffff013f1fd63300 x12: 0000000000000006
|
|
x11: ffffdc7e128f4420 x10: 0000000000000000 x9 : ffffdc7e111badec
|
|
x8 : ffff00802b251980 x7 : 0000000000000000 x6 : ffff0080139d0028
|
|
x5 : 0000000000000000 x4 : ffff0080139d0018 x3 : 00000000ffffffff
|
|
x2 : 0000000000000008 x1 : ffff8000155ab7a0 x0 : 0000000000000000
|
|
Kernel panic - not syncing: Asynchronous SError Interrupt
|
|
CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted
|
|
5.15.2.1-13 #1
|
|
Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION
|
|
Call trace:
|
|
dump_backtrace+0x0/0x1e0
|
|
show_stack+0x24/0x30
|
|
dump_stack_lvl+0x8c/0xb8
|
|
dump_stack+0x18/0x34
|
|
panic+0x16c/0x384
|
|
add_taint+0x0/0xc0
|
|
arm64_serror_panic+0x7c/0x90
|
|
arm64_is_fatal_ras_serror+0x34/0xa4
|
|
do_serror+0x50/0x6c
|
|
el1h_64_error_handler+0x40/0x74
|
|
el1h_64_error+0x7c/0x80
|
|
cppc_get_perf_caps+0xec/0x410
|
|
cppc_cpufreq_cpu_init+0x74/0x400 [cppc_cpufreq]
|
|
cpufreq_online+0x2dc/0xa30
|
|
cpufreq_add_dev+0xc0/0xd4
|
|
subsys_interface_register+0x134/0x14c
|
|
cpufreq_register_driver+0x1b0/0x354
|
|
cppc_cpufreq_init+0x1a8/0x1000 [cppc_cpufreq]
|
|
do_one_initcall+0x50/0x250
|
|
do_init_module+0x60/0x27c
|
|
load_module+0x2300/0x2570
|
|
__do_sys_finit_module+0xa8/0x114
|
|
__arm64_sys_finit_module+0x2c/0x3c
|
|
invoke_syscall+0x78/0x100
|
|
el0_svc_common.constprop.0+0x180/0x1a0
|
|
do_el0_svc+0x84/0xa0
|
|
el0_svc+0x2c/0xc0
|
|
el0t_64_sync_handler+0xa4/0x12c
|
|
el0t_64_sync+0x1a4/0x1a8
|
|
|
|
Instead, use access_width to determine the size and use the offset and
|
|
width to shift and mask the bits to read/write out. Make sure to add a
|
|
check for system memory since pcc redefines the access_width to
|
|
subspace id.
|
|
|
|
If access_width is not set, then fall back to using bit_width.
|
|
|
|
[ rjw: Subject and changelog edits, comment adjustments ](CVE-2024-35995)
|
|
|
|
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:
|
|
|
|
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-SP1.
|
|
|
|
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-1693</URL>
|
|
</Reference>
|
|
<Reference Type="openEuler CVE">
|
|
<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-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-52655</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-52699</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52703</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52730</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52735</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52736</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-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-52802</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52804</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52805</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52808</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-52818</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-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-52845</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52858</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2023-52859</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-52871</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-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-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-35877</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-35984</URL>
|
|
<URL>https://www.openeuler.org/en/security/cve/detail.html?id=CVE-2024-35995</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-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-47370</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-52655</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52669</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52699</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52703</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52730</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52735</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52736</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-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-52802</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52804</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52805</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52808</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52814</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52818</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-52832</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52836</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52845</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52858</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52859</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52864</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2023-52871</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-27401</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-27413</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-35877</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-35984</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-35995</URL>
|
|
<URL>https://nvd.nist.gov/vuln/detail/CVE-2024-36000</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-SP1" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">openEuler-22.03-LTS-SP1</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="aarch64">
|
|
<FullProductName ProductID="kernel-devel-5.10.0-136.78.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-devel-5.10.0-136.78.0.158.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-136.78.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">python3-perf-debuginfo-5.10.0-136.78.0.158.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-136.78.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-debuginfo-5.10.0-136.78.0.158.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-5.10.0-136.78.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">perf-5.10.0-136.78.0.158.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-5.10.0-136.78.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-devel-5.10.0-136.78.0.158.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-5.10.0-136.78.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">python3-perf-5.10.0-136.78.0.158.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-5.10.0-136.78.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-5.10.0-136.78.0.158.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-5.10.0-136.78.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-debuginfo-5.10.0-136.78.0.158.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-5.10.0-136.78.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-5.10.0-136.78.0.158.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-5.10.0-136.78.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-headers-5.10.0-136.78.0.158.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-5.10.0-136.78.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-source-5.10.0-136.78.0.158.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-5.10.0-136.78.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-debugsource-5.10.0-136.78.0.158.oe2203sp1.aarch64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-5.10.0-136.78.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">perf-debuginfo-5.10.0-136.78.0.158.oe2203sp1.aarch64.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="src">
|
|
<FullProductName ProductID="kernel-5.10.0-136.78.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-5.10.0-136.78.0.158.oe2203sp1.src.rpm</FullProductName>
|
|
</Branch>
|
|
<Branch Type="Package Arch" Name="x86_64">
|
|
<FullProductName ProductID="perf-5.10.0-136.78.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">perf-5.10.0-136.78.0.158.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-devel-5.10.0-136.78.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-devel-5.10.0-136.78.0.158.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-5.10.0-136.78.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-5.10.0-136.78.0.158.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-headers-5.10.0-136.78.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-headers-5.10.0-136.78.0.158.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-source-5.10.0-136.78.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-source-5.10.0-136.78.0.158.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="perf-debuginfo-5.10.0-136.78.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">perf-debuginfo-5.10.0-136.78.0.158.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-5.10.0-136.78.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-5.10.0-136.78.0.158.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-tools-debuginfo-5.10.0-136.78.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-tools-debuginfo-5.10.0-136.78.0.158.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debugsource-5.10.0-136.78.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-debugsource-5.10.0-136.78.0.158.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-devel-5.10.0-136.78.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-devel-5.10.0-136.78.0.158.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-debuginfo-5.10.0-136.78.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">python3-perf-debuginfo-5.10.0-136.78.0.158.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="kernel-debuginfo-5.10.0-136.78.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">kernel-debuginfo-5.10.0-136.78.0.158.oe2203sp1.x86_64.rpm</FullProductName>
|
|
<FullProductName ProductID="python3-perf-5.10.0-136.78.0.158" CPE="cpe:/a:openEuler:openEuler:22.03-LTS-SP1">python3-perf-5.10.0-136.78.0.158.oe2203sp1.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:
|
|
|
|
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-SP1</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-1693</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:
|
|
|
|
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-SP1</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-1693</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: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-SP1</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-1693</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:
|
|
|
|
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-SP1</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-1693</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:
|
|
|
|
usb: aqc111: check packet for fixup for true limit
|
|
|
|
If a device sends a packet that is inbetween 0
|
|
and sizeof(u64) the value passed to skb_trim()
|
|
as length will wrap around ending up as some very
|
|
large value.
|
|
|
|
The driver will then proceed to parse the header
|
|
located at that position, which will either oops or
|
|
process some random value.
|
|
|
|
The fix is to check against sizeof(u64) rather than
|
|
0, which the driver currently does. The issue exists
|
|
since the introduction of the driver.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52655</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-1693</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:
|
|
|
|
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-SP1</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-1693</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:
|
|
|
|
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-SP1</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-1693</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:
|
|
|
|
net/usb: kalmia: Don't pass act_len in usb_bulk_msg error path
|
|
|
|
syzbot reported that act_len in kalmia_send_init_packet() is
|
|
uninitialized when passing it to the first usb_bulk_msg error path. Jiri
|
|
Pirko noted that it's pointless to pass it in the error path, and that
|
|
the value that would be printed in the second error path would be the
|
|
value of act_len from the first call to usb_bulk_msg.[1]
|
|
|
|
With this in mind, let's just not pass act_len to the usb_bulk_msg error
|
|
paths.
|
|
|
|
1: https://lore.kernel.org/lkml/Y9pY61y1nwTuzMOa@nanopsycho/</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52703</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-1693</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:
|
|
|
|
mmc: sdio: fix possible resource leaks in some error paths
|
|
|
|
If sdio_add_func() or sdio_init_func() fails, sdio_remove_func() can
|
|
not release the resources, because the sdio function is not presented
|
|
in these two cases, it won't call of_node_put() or put_device().
|
|
|
|
To fix these leaks, make sdio_func_present() only control whether
|
|
device_del() needs to be called or not, then always call of_node_put()
|
|
and put_device().
|
|
|
|
In error case in sdio_init_func(), the reference of 'card->dev' is
|
|
not get, to avoid redundant put in sdio_free_func_cis(), move the
|
|
get_device() to sdio_alloc_func() and put_device() to sdio_release_func(),
|
|
it can keep the get/put function be balanced.
|
|
|
|
Without this patch, while doing fault inject test, it can get the
|
|
following leak reports, after this fix, the leak is gone.
|
|
|
|
unreferenced object 0xffff888112514000 (size 2048):
|
|
comm "kworker/3:2", pid 65, jiffies 4294741614 (age 124.774s)
|
|
hex dump (first 32 bytes):
|
|
00 e0 6f 12 81 88 ff ff 60 58 8d 06 81 88 ff ff ..o.....`X......
|
|
10 40 51 12 81 88 ff ff 10 40 51 12 81 88 ff ff .@Q......@Q.....
|
|
backtrace:
|
|
[<000000009e5931da>] kmalloc_trace+0x21/0x110
|
|
[<000000002f839ccb>] mmc_alloc_card+0x38/0xb0 [mmc_core]
|
|
[<0000000004adcbf6>] mmc_sdio_init_card+0xde/0x170 [mmc_core]
|
|
[<000000007538fea0>] mmc_attach_sdio+0xcb/0x1b0 [mmc_core]
|
|
[<00000000d4fdeba7>] mmc_rescan+0x54a/0x640 [mmc_core]
|
|
|
|
unreferenced object 0xffff888112511000 (size 2048):
|
|
comm "kworker/3:2", pid 65, jiffies 4294741623 (age 124.766s)
|
|
hex dump (first 32 bytes):
|
|
00 40 51 12 81 88 ff ff e0 58 8d 06 81 88 ff ff .@Q......X......
|
|
10 10 51 12 81 88 ff ff 10 10 51 12 81 88 ff ff ..Q.......Q.....
|
|
backtrace:
|
|
[<000000009e5931da>] kmalloc_trace+0x21/0x110
|
|
[<00000000fcbe706c>] sdio_alloc_func+0x35/0x100 [mmc_core]
|
|
[<00000000c68f4b50>] mmc_attach_sdio.cold.18+0xb1/0x395 [mmc_core]
|
|
[<00000000d4fdeba7>] mmc_rescan+0x54a/0x640 [mmc_core]</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52730</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-1693</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:
|
|
|
|
bpf, sockmap: Don't let sock_map_{close,destroy,unhash} call itself
|
|
|
|
sock_map proto callbacks should never call themselves by design. Protect
|
|
against bugs like [1] and break out of the recursive loop to avoid a stack
|
|
overflow in favor of a resource leak.
|
|
|
|
[1] https://lore.kernel.org/all/00000000000073b14905ef2e7401@google.com/</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52735</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-1693</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:
|
|
|
|
ALSA: hda: Do not unset preset when cleaning up codec
|
|
|
|
Several functions that take part in codec's initialization and removal
|
|
are re-used by ASoC codec drivers implementations. Drivers mimic the
|
|
behavior of hda_codec_driver_probe/remove() found in
|
|
sound/pci/hda/hda_bind.c with their component->probe/remove() instead.
|
|
|
|
One of the reasons for that is the expectation of
|
|
snd_hda_codec_device_new() to receive a valid pointer to an instance of
|
|
struct snd_card. This expectation can be met only once sound card
|
|
components probing commences.
|
|
|
|
As ASoC sound card may be unbound without codec device being actually
|
|
removed from the system, unsetting ->preset in
|
|
snd_hda_codec_cleanup_for_unbind() interferes with module unload -> load
|
|
scenario causing null-ptr-deref. Preset is assigned only once, during
|
|
device/driver matching whereas ASoC codec driver's module reloading may
|
|
occur several times throughout the lifetime of an audio stack.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52736</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-1693</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-SP1</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-1693</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-SP1</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-1693</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:
|
|
|
|
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-SP1</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-1693</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:
|
|
|
|
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-SP1</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-1693</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:
|
|
|
|
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-SP1</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-1693</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:
|
|
|
|
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-SP1</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-1693</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: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-SP1</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-1693</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:
|
|
|
|
fs/jfs: Add validity check for db_maxag and db_agpref
|
|
|
|
Both db_maxag and db_agpref are used as the index of the
|
|
db_agfree array, but there is currently no validity check for
|
|
db_maxag and db_agpref, which can lead to errors.
|
|
|
|
The following is related bug reported by Syzbot:
|
|
|
|
UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:639:20
|
|
index 7936 is out of range for type 'atomic_t[128]'
|
|
|
|
Add checking that the values of db_maxag and db_agpref are valid
|
|
indexes for the db_agfree array.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52804</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-1693</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:
|
|
|
|
jfs: fix array-index-out-of-bounds in diAlloc
|
|
|
|
Currently there is not check against the agno of the iag while
|
|
allocating new inodes to avoid fragmentation problem. Added the check
|
|
which is required.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52805</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-1693</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:
|
|
|
|
scsi: hisi_sas: Set debugfs_dir pointer to NULL after removing debugfs
|
|
|
|
If init debugfs failed during device registration due to memory allocation
|
|
failure, debugfs_remove_recursive() is called, after which debugfs_dir is
|
|
not set to NULL. debugfs_remove_recursive() will be called again during
|
|
device removal. As a result, illegal pointer is accessed.
|
|
|
|
[ 1665.467244] hisi_sas_v3_hw 0000:b4:02.0: failed to init debugfs!
|
|
...
|
|
[ 1669.836708] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0
|
|
[ 1669.872669] pc : down_write+0x24/0x70
|
|
[ 1669.876315] lr : down_write+0x1c/0x70
|
|
[ 1669.879961] sp : ffff000036f53a30
|
|
[ 1669.883260] x29: ffff000036f53a30 x28: ffffa027c31549f8
|
|
[ 1669.888547] x27: ffffa027c3140000 x26: 0000000000000000
|
|
[ 1669.893834] x25: ffffa027bf37c270 x24: ffffa027bf37c270
|
|
[ 1669.899122] x23: ffff0000095406b8 x22: ffff0000095406a8
|
|
[ 1669.904408] x21: 0000000000000000 x20: ffffa027bf37c310
|
|
[ 1669.909695] x19: 00000000000000a0 x18: ffff8027dcd86f10
|
|
[ 1669.914982] x17: 0000000000000000 x16: 0000000000000000
|
|
[ 1669.920268] x15: 0000000000000000 x14: ffffa0274014f870
|
|
[ 1669.925555] x13: 0000000000000040 x12: 0000000000000228
|
|
[ 1669.930842] x11: 0000000000000020 x10: 0000000000000bb0
|
|
[ 1669.936129] x9 : ffff000036f537f0 x8 : ffff80273088ca10
|
|
[ 1669.941416] x7 : 000000000000001d x6 : 00000000ffffffff
|
|
[ 1669.946702] x5 : ffff000008a36310 x4 : ffff80273088be00
|
|
[ 1669.951989] x3 : ffff000009513e90 x2 : 0000000000000000
|
|
[ 1669.957276] x1 : 00000000000000a0 x0 : ffffffff00000001
|
|
[ 1669.962563] Call trace:
|
|
[ 1669.965000] down_write+0x24/0x70
|
|
[ 1669.968301] debugfs_remove_recursive+0x5c/0x1b0
|
|
[ 1669.972905] hisi_sas_debugfs_exit+0x24/0x30 [hisi_sas_main]
|
|
[ 1669.978541] hisi_sas_v3_remove+0x130/0x150 [hisi_sas_v3_hw]
|
|
[ 1669.984175] pci_device_remove+0x48/0xd8
|
|
[ 1669.988082] device_release_driver_internal+0x1b4/0x250
|
|
[ 1669.993282] device_release_driver+0x28/0x38
|
|
[ 1669.997534] pci_stop_bus_device+0x84/0xb8
|
|
[ 1670.001611] pci_stop_and_remove_bus_device_locked+0x24/0x40
|
|
[ 1670.007244] remove_store+0xfc/0x140
|
|
[ 1670.010802] dev_attr_store+0x44/0x60
|
|
[ 1670.014448] sysfs_kf_write+0x58/0x80
|
|
[ 1670.018095] kernfs_fop_write+0xe8/0x1f0
|
|
[ 1670.022000] __vfs_write+0x60/0x190
|
|
[ 1670.025472] vfs_write+0xac/0x1c0
|
|
[ 1670.028771] ksys_write+0x6c/0xd8
|
|
[ 1670.032071] __arm64_sys_write+0x24/0x30
|
|
[ 1670.035977] el0_svc_common+0x78/0x130
|
|
[ 1670.039710] el0_svc_handler+0x38/0x78
|
|
[ 1670.043442] el0_svc+0x8/0xc
|
|
|
|
To fix this, set debugfs_dir to NULL after debugfs_remove_recursive().</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52808</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-1693</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: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-SP1</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-1693</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:
|
|
|
|
drm/amd: Fix UBSAN array-index-out-of-bounds for SMU7
|
|
|
|
For pptable structs that use flexible array sizes, use flexible arrays.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52818</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-1693</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:
|
|
|
|
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-SP1</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-1693</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/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-SP1</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-1693</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
<Vulnerability Ordinal="26" xmlns="http://www.icasi.org/CVRF/schema/vuln/1.1">
|
|
<Notes>
|
|
<Note Title="Vulnerability Description" Type="General" Ordinal="26" xml:lang="en">In the Linux kernel, the following vulnerability has been resolved:
|
|
|
|
wifi: 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-SP1</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-1693</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:
|
|
|
|
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-SP1</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-1693</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:
|
|
|
|
tipc: Change nla_policy for bearer-related names to NLA_NUL_STRING
|
|
|
|
syzbot reported the following uninit-value access issue [1]:
|
|
|
|
=====================================================
|
|
BUG: KMSAN: uninit-value in strlen lib/string.c:418 [inline]
|
|
BUG: KMSAN: uninit-value in strstr+0xb8/0x2f0 lib/string.c:756
|
|
strlen lib/string.c:418 [inline]
|
|
strstr+0xb8/0x2f0 lib/string.c:756
|
|
tipc_nl_node_reset_link_stats+0x3ea/0xb50 net/tipc/node.c:2595
|
|
genl_family_rcv_msg_doit net/netlink/genetlink.c:971 [inline]
|
|
genl_family_rcv_msg net/netlink/genetlink.c:1051 [inline]
|
|
genl_rcv_msg+0x11ec/0x1290 net/netlink/genetlink.c:1066
|
|
netlink_rcv_skb+0x371/0x650 net/netlink/af_netlink.c:2545
|
|
genl_rcv+0x40/0x60 net/netlink/genetlink.c:1075
|
|
netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline]
|
|
netlink_unicast+0xf47/0x1250 net/netlink/af_netlink.c:1368
|
|
netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
sock_sendmsg net/socket.c:753 [inline]
|
|
____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541
|
|
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595
|
|
__sys_sendmsg net/socket.c:2624 [inline]
|
|
__do_sys_sendmsg net/socket.c:2633 [inline]
|
|
__se_sys_sendmsg net/socket.c:2631 [inline]
|
|
__x64_sys_sendmsg+0x307/0x490 net/socket.c:2631
|
|
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
|
|
do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
|
|
entry_SYSCALL_64_after_hwframe+0x63/0xcd
|
|
|
|
Uninit was created at:
|
|
slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767
|
|
slab_alloc_node mm/slub.c:3478 [inline]
|
|
kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523
|
|
kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:559
|
|
__alloc_skb+0x318/0x740 net/core/skbuff.c:650
|
|
alloc_skb include/linux/skbuff.h:1286 [inline]
|
|
netlink_alloc_large_skb net/netlink/af_netlink.c:1214 [inline]
|
|
netlink_sendmsg+0xb34/0x13d0 net/netlink/af_netlink.c:1885
|
|
sock_sendmsg_nosec net/socket.c:730 [inline]
|
|
sock_sendmsg net/socket.c:753 [inline]
|
|
____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541
|
|
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595
|
|
__sys_sendmsg net/socket.c:2624 [inline]
|
|
__do_sys_sendmsg net/socket.c:2633 [inline]
|
|
__se_sys_sendmsg net/socket.c:2631 [inline]
|
|
__x64_sys_sendmsg+0x307/0x490 net/socket.c:2631
|
|
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
|
|
do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
|
|
entry_SYSCALL_64_after_hwframe+0x63/0xcd
|
|
|
|
TIPC bearer-related names including link names must be null-terminated
|
|
strings. If a link name which is not null-terminated is passed through
|
|
netlink, strstr() and similar functions can cause buffer overrun. This
|
|
causes the above issue.
|
|
|
|
This patch changes the nla_policy for bearer-related names from NLA_STRING
|
|
to NLA_NUL_STRING. This resolves the issue by ensuring that only
|
|
null-terminated strings are accepted as bearer-related names.
|
|
|
|
syzbot reported similar uninit-value issue related to bearer names [2]. The
|
|
root cause of this issue is that a non-null-terminated bearer name was
|
|
passed. This patch also resolved this issue.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52845</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-1693</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:
|
|
|
|
clk: mediatek: clk-mt7629: 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-52858</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-1693</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:
|
|
|
|
perf: hisi: Fix use-after-free when register pmu fails
|
|
|
|
When we fail to register the uncore pmu, the pmu context may not been
|
|
allocated. The error handing will call cpuhp_state_remove_instance()
|
|
to call uncore pmu offline callback, which migrate the pmu context.
|
|
Since that's liable to lead to some kind of use-after-free.
|
|
|
|
Use cpuhp_state_remove_instance_nocalls() instead of
|
|
cpuhp_state_remove_instance() so that the notifiers don't execute after
|
|
the PMU device has been failed to register.</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2023-52859</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-1693</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:
|
|
|
|
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-SP1</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-1693</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:
|
|
|
|
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-SP1</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-1693</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:
|
|
|
|
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-SP1</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-1693</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:
|
|
|
|
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-SP1</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-1693</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:
|
|
|
|
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-SP1</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-1693</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: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-SP1</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-1693</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: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-SP1</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-1693</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:
|
|
|
|
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-SP1</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-1693</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:
|
|
|
|
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-SP1</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-1693</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:
|
|
|
|
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-SP1</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-1693</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:
|
|
|
|
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-SP1</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-1693</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:
|
|
|
|
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-SP1</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-1693</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:
|
|
|
|
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-SP1</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-1693</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:
|
|
|
|
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-SP1</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-1693</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:
|
|
|
|
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-SP1</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-1693</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:
|
|
|
|
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-SP1</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-1693</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:
|
|
|
|
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-SP1</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-1693</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:
|
|
|
|
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-SP1</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-1693</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: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-SP1</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-1693</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:i2c: smbus: fix NULL function pointer dereferenceBaruch reported an OOPS when using the designware controller as targetonly. Target-only modes break the assumption of one transfer functionalways being available. Fix this by always checking the pointer in__i2c_transfer.[wsa: dropped the simplification in core-smbus to avoid theoretical regressions]</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2024-35984</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-1693</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:
|
|
|
|
ACPI: CPPC: Use access_width over bit_width for system memory accesses
|
|
|
|
To align with ACPI 6.3+, since bit_width can be any 8-bit value, it
|
|
cannot be depended on to be always on a clean 8b boundary. This was
|
|
uncovered on the Cobalt 100 platform.
|
|
|
|
SError Interrupt on CPU26, code 0xbe000011 -- SError
|
|
CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted 5.15.2.1-13 #1
|
|
Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION
|
|
pstate: 62400009 (nZCv daif +PAN -UAO +TCO -DIT -SSBS BTYPE=--)
|
|
pc : cppc_get_perf_caps+0xec/0x410
|
|
lr : cppc_get_perf_caps+0xe8/0x410
|
|
sp : ffff8000155ab730
|
|
x29: ffff8000155ab730 x28: ffff0080139d0038 x27: ffff0080139d0078
|
|
x26: 0000000000000000 x25: ffff0080139d0058 x24: 00000000ffffffff
|
|
x23: ffff0080139d0298 x22: ffff0080139d0278 x21: 0000000000000000
|
|
x20: ffff00802b251910 x19: ffff0080139d0000 x18: ffffffffffffffff
|
|
x17: 0000000000000000 x16: ffffdc7e111bad04 x15: ffff00802b251008
|
|
x14: ffffffffffffffff x13: ffff013f1fd63300 x12: 0000000000000006
|
|
x11: ffffdc7e128f4420 x10: 0000000000000000 x9 : ffffdc7e111badec
|
|
x8 : ffff00802b251980 x7 : 0000000000000000 x6 : ffff0080139d0028
|
|
x5 : 0000000000000000 x4 : ffff0080139d0018 x3 : 00000000ffffffff
|
|
x2 : 0000000000000008 x1 : ffff8000155ab7a0 x0 : 0000000000000000
|
|
Kernel panic - not syncing: Asynchronous SError Interrupt
|
|
CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted
|
|
5.15.2.1-13 #1
|
|
Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION
|
|
Call trace:
|
|
dump_backtrace+0x0/0x1e0
|
|
show_stack+0x24/0x30
|
|
dump_stack_lvl+0x8c/0xb8
|
|
dump_stack+0x18/0x34
|
|
panic+0x16c/0x384
|
|
add_taint+0x0/0xc0
|
|
arm64_serror_panic+0x7c/0x90
|
|
arm64_is_fatal_ras_serror+0x34/0xa4
|
|
do_serror+0x50/0x6c
|
|
el1h_64_error_handler+0x40/0x74
|
|
el1h_64_error+0x7c/0x80
|
|
cppc_get_perf_caps+0xec/0x410
|
|
cppc_cpufreq_cpu_init+0x74/0x400 [cppc_cpufreq]
|
|
cpufreq_online+0x2dc/0xa30
|
|
cpufreq_add_dev+0xc0/0xd4
|
|
subsys_interface_register+0x134/0x14c
|
|
cpufreq_register_driver+0x1b0/0x354
|
|
cppc_cpufreq_init+0x1a8/0x1000 [cppc_cpufreq]
|
|
do_one_initcall+0x50/0x250
|
|
do_init_module+0x60/0x27c
|
|
load_module+0x2300/0x2570
|
|
__do_sys_finit_module+0xa8/0x114
|
|
__arm64_sys_finit_module+0x2c/0x3c
|
|
invoke_syscall+0x78/0x100
|
|
el0_svc_common.constprop.0+0x180/0x1a0
|
|
do_el0_svc+0x84/0xa0
|
|
el0_svc+0x2c/0xc0
|
|
el0t_64_sync_handler+0xa4/0x12c
|
|
el0t_64_sync+0x1a4/0x1a8
|
|
|
|
Instead, use access_width to determine the size and use the offset and
|
|
width to shift and mask the bits to read/write out. Make sure to add a
|
|
check for system memory since pcc redefines the access_width to
|
|
subspace id.
|
|
|
|
If access_width is not set, then fall back to using bit_width.
|
|
|
|
[ rjw: Subject and changelog edits, comment adjustments ]</Note>
|
|
</Notes>
|
|
<ReleaseDate>2024-06-07</ReleaseDate>
|
|
<CVE>CVE-2024-35995</CVE>
|
|
<ProductStatuses>
|
|
<Status Type="Fixed">
|
|
<ProductID>openEuler-22.03-LTS-SP1</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-1693</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:
|
|
|
|
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-SP1</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-1693</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:
|
|
|
|
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-SP1</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-1693</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:
|
|
|
|
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-SP1</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-1693</URL>
|
|
</Remediation>
|
|
</Remediations>
|
|
</Vulnerability>
|
|
</cvrfdoc> |