<?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-&gt;size_goal - skb-&gt;len &gt; 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 &lt;0f&gt; 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 &lt;48&gt; 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 &gt;= 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 &lt;tdwilliamsiv@gmail.com&gt;
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 (&quot;net: introduce
__skb_fill_page_desc_noacc&quot;) as a prereq.

Race is more probable after commit c07aea3ef4d4
(&quot;mm: add a signature in struct page&quot;) because page_is_pfmemalloc()
is now using low order bit from page-&gt;lru.next, which can change
more often than page-&gt;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 -&gt; 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&apos;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&apos;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&apos;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 &quot;write_lock(&amp;pointers_lock) =&gt; read_lock(&amp;pointers_lock) deadlock&quot; bug
and a &quot;sb_bread() with write_lock(&amp;pointers_lock)&quot; bug were introduced by
&quot;Replace BKL for chain locking with sysvfs-private rwlock&quot; in Linux 2.5.12.

Then, &quot;[PATCH] err1-40: sysvfs locking fix&quot; in Linux 2.6.8 fixed the
former bug by moving pointers_lock lock to the callers, but instead
introduced a &quot;sb_bread() with read_lock(&amp;pointers_lock)&quot; 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 &quot;[PATCH] err1-40: sysvfs locking fix&quot; except that get_branch()
 from with find_shared() is called without write_lock(&amp;pointers_lock).(CVE-2023-52699)

In the Linux kernel, the following vulnerability has been resolved:

net/usb: kalmia: Don&apos;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&apos;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&apos;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&apos;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 &apos;card-&gt;dev&apos; 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 &quot;kworker/3:2&quot;, 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:
    [&lt;000000009e5931da&gt;] kmalloc_trace+0x21/0x110
    [&lt;000000002f839ccb&gt;] mmc_alloc_card+0x38/0xb0 [mmc_core]
    [&lt;0000000004adcbf6&gt;] mmc_sdio_init_card+0xde/0x170 [mmc_core]
    [&lt;000000007538fea0&gt;] mmc_attach_sdio+0xcb/0x1b0 [mmc_core]
    [&lt;00000000d4fdeba7&gt;] mmc_rescan+0x54a/0x640 [mmc_core]

unreferenced object 0xffff888112511000 (size 2048):
  comm &quot;kworker/3:2&quot;, 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:
    [&lt;000000009e5931da&gt;] kmalloc_trace+0x21/0x110
    [&lt;00000000fcbe706c&gt;] sdio_alloc_func+0x35/0x100 [mmc_core]
    [&lt;00000000c68f4b50&gt;] mmc_attach_sdio.cold.18+0xb1/0x395 [mmc_core]
    [&lt;00000000d4fdeba7&gt;] mmc_rescan+0x54a/0x640 [mmc_core](CVE-2023-52730)

In the Linux kernel, the following vulnerability has been resolved:

bpf, sockmap: Don&apos;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&apos;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-&gt;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 -&gt;preset in
snd_hda_codec_cleanup_for_unbind() interferes with module unload -&gt; load
scenario causing null-ptr-deref. Preset is assigned only once, during
device/driver matching whereas ASoC codec driver&apos;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&apos;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 (&quot;arm64: Use a positive cpucap for FP/SIMD&quot;)

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&apos;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-&gt;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]  &lt;TASK&gt;
  [  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&apos;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&apos;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 &quot;v&quot;.  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 &apos;atomic_t[128]&apos;

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&apos;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 &quot;unset power level&quot;.

 UBSAN: signed-integer-overflow in net/wireless/nl80211.c:3816:5
 -2147483648 * 100 cannot be represented in type &apos;int&apos;
 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
&quot;struct stress&quot; 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&apos;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&apos;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&apos;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 (&quot;drivers: misc: pass miscdevice pointer via
file private data&quot;), the miscdevice stores a pointer to itself inside
filp-&gt;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&apos;t crash kernel if can_priv::echo_skb is accessed out of bounds

If the &quot;struct can_priv::echoo_skb&quot; 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 &quot;(udev-worker)&quot;, 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):
    [&lt;ffffffff993495ed&gt;] kmalloc_trace+0x29d/0x340
    [&lt;ffffffffc0ea4a94&gt;] dm_dmub_sw_init+0xb4/0x450 [amdgpu]
    [&lt;ffffffffc0ea4e55&gt;] dm_sw_init+0x15/0x2b0 [amdgpu]
    [&lt;ffffffffc0ba8557&gt;] amdgpu_device_init+0x1417/0x24e0 [amdgpu]
    [&lt;ffffffffc0bab285&gt;] amdgpu_driver_load_kms+0x15/0x190 [amdgpu]
    [&lt;ffffffffc0ba09c7&gt;] amdgpu_pci_probe+0x187/0x4e0 [amdgpu]
    [&lt;ffffffff9968fd1e&gt;] local_pci_probe+0x3e/0x90
    [&lt;ffffffff996918a3&gt;] pci_device_probe+0xc3/0x230
    [&lt;ffffffff99805872&gt;] really_probe+0xe2/0x480
    [&lt;ffffffff99805c98&gt;] __driver_probe_device+0x78/0x160
    [&lt;ffffffff99805daf&gt;] driver_probe_device+0x1f/0x90
    [&lt;ffffffff9980601e&gt;] __driver_attach+0xce/0x1c0
    [&lt;ffffffff99803170&gt;] bus_for_each_dev+0x70/0xc0
    [&lt;ffffffff99804822&gt;] bus_add_driver+0x112/0x210
    [&lt;ffffffff99807245&gt;] driver_register+0x55/0x100
    [&lt;ffffffff990012d1&gt;] 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): [&lt;ffffffc0812416f8&gt;] _raw_spin_unlock_irqrestore+0x70/0xb0
    hardirqs last disabled at (40): [&lt;ffffffc08122d208&gt;] el1_dbg+0x28/0x90
    softirqs last  enabled at (36): [&lt;ffffffc080017dec&gt;] kernel_neon_begin+0x8c/0xf0
    softirqs last disabled at (34): [&lt;ffffffc080017dc0&gt;] 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&apos;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&apos;t complete
until the device lock has been released, and the lock won&apos;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 &lt;samsun1006219@gmail.com&gt;
Reported by: xingwei lee &lt;xrivendell7@gmail.com&gt;(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 &apos;efi_capsule_open&apos;:
drivers/firmware/efi/capsule-loader.c:295:24: error: allocation of insufficient size &apos;4&apos; for type &apos;phys_addr_t&apos; {aka &apos;long long unsigned int&apos;} with size &apos;8&apos; [-Werror=alloc-size]
  295 |         cap_info-&gt;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 (&quot;vt: fix memory overlapping when deleting chars in the
buffer&quot;). 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&apos;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&apos;t call memtype_free() or would call
it with the wrong range, possibly leaking memory.

To fix that, let&apos;s update follow_phys() to refuse returning anon folios,
and fallback to using the stored PFN inside vma-&gt;vm_pgoff for COW mappings
if we run into that.

We will now properly handle untrack_pfn() with COW mappings, where we
don&apos;t need the cachemode.  We&apos;ll have to fail fork()-&gt;track_pfn_copy() if
the first page was replaced by an anon folio, though: we&apos;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():

&lt;--- C reproducer ---&gt;
 #include &lt;stdio.h&gt;
 #include &lt;sys/mman.h&gt;
 #include &lt;unistd.h&gt;
 #include &lt;liburing.h&gt;

 int main(void)
 {
         struct io_uring_params p = {};
         int ring_fd;
         size_t size;
         char *map;

         ring_fd = io_uring_setup(1, &amp;p);
         if (ring_fd &lt; 0) {
                 perror(&quot;io_uring_setup&quot;);
                 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(&quot;mmap&quot;);
                 return 1;
         }

         /* We have at least one page. Let&apos;s COW it. */
         *map = 0;
         pause();
         return 0;
 }
&lt;--- C reproducer ---&gt;

On a system with 16 GiB RAM and swap configured:
 # ./iouring &amp;
 # 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]  &lt;TASK&gt;
[  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-&gt;mode_config.mutex

The modes[] array contains pointers to modes on the connectors&apos;
mode lists, which are protected by dev-&gt;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&apos;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&apos;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&apos;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&apos;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-&gt;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 &apos;hci_req_sync_complete()&apos;, 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(&amp;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 &quot;pctldev&quot; struct is allocated in devm_pinctrl_register_and_init().
It&apos;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-&gt;size_goal - skb-&gt;len &gt; 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 &lt;0f&gt; 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 &lt;48&gt; 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 &gt;= 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 &lt;tdwilliamsiv@gmail.com&gt;
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-&gt;lru.next, which can changemore often than page-&gt;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 -&gt; 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&apos;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&apos;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&apos;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 &quot;write_lock(&amp;pointers_lock) =&gt; read_lock(&amp;pointers_lock) deadlock&quot; bug
and a &quot;sb_bread() with write_lock(&amp;pointers_lock)&quot; bug were introduced by
&quot;Replace BKL for chain locking with sysvfs-private rwlock&quot; in Linux 2.5.12.

Then, &quot;[PATCH] err1-40: sysvfs locking fix&quot; in Linux 2.6.8 fixed the
former bug by moving pointers_lock lock to the callers, but instead
introduced a &quot;sb_bread() with read_lock(&amp;pointers_lock)&quot; 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 &quot;[PATCH] err1-40: sysvfs locking fix&quot; except that get_branch()
 from with find_shared() is called without write_lock(&amp;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&apos;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&apos;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&apos;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&apos;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 &apos;card-&gt;dev&apos; 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 &quot;kworker/3:2&quot;, 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:
    [&lt;000000009e5931da&gt;] kmalloc_trace+0x21/0x110
    [&lt;000000002f839ccb&gt;] mmc_alloc_card+0x38/0xb0 [mmc_core]
    [&lt;0000000004adcbf6&gt;] mmc_sdio_init_card+0xde/0x170 [mmc_core]
    [&lt;000000007538fea0&gt;] mmc_attach_sdio+0xcb/0x1b0 [mmc_core]
    [&lt;00000000d4fdeba7&gt;] mmc_rescan+0x54a/0x640 [mmc_core]

unreferenced object 0xffff888112511000 (size 2048):
  comm &quot;kworker/3:2&quot;, 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:
    [&lt;000000009e5931da&gt;] kmalloc_trace+0x21/0x110
    [&lt;00000000fcbe706c&gt;] sdio_alloc_func+0x35/0x100 [mmc_core]
    [&lt;00000000c68f4b50&gt;] mmc_attach_sdio.cold.18+0xb1/0x395 [mmc_core]
    [&lt;00000000d4fdeba7&gt;] 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&apos;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&apos;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-&gt;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 -&gt;preset in
snd_hda_codec_cleanup_for_unbind() interferes with module unload -&gt; load
scenario causing null-ptr-deref. Preset is assigned only once, during
device/driver matching whereas ASoC codec driver&apos;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&apos;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 (&quot;arm64: Use a positive cpucap for FP/SIMD&quot;)

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&apos;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-&gt;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]  &lt;TASK&gt;  [  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&apos;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&apos;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 &quot;v&quot;.  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 &apos;atomic_t[128]&apos;

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&apos;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 &quot;unset power level&quot;.

 UBSAN: signed-integer-overflow in net/wireless/nl80211.c:3816:5
 -2147483648 * 100 cannot be represented in type &apos;int&apos;
 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
&quot;struct stress&quot; 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&apos;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&apos;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&apos;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 (&quot;drivers: misc: pass miscdevice pointer via
file private data&quot;), the miscdevice stores a pointer to itself inside
filp-&gt;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&apos;t crash kernel if can_priv::echo_skb is accessed out of bounds

If the &quot;struct can_priv::echoo_skb&quot; 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 &quot;(udev-worker)&quot;, 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):
    [&lt;ffffffff993495ed&gt;] kmalloc_trace+0x29d/0x340
    [&lt;ffffffffc0ea4a94&gt;] dm_dmub_sw_init+0xb4/0x450 [amdgpu]
    [&lt;ffffffffc0ea4e55&gt;] dm_sw_init+0x15/0x2b0 [amdgpu]
    [&lt;ffffffffc0ba8557&gt;] amdgpu_device_init+0x1417/0x24e0 [amdgpu]
    [&lt;ffffffffc0bab285&gt;] amdgpu_driver_load_kms+0x15/0x190 [amdgpu]
    [&lt;ffffffffc0ba09c7&gt;] amdgpu_pci_probe+0x187/0x4e0 [amdgpu]
    [&lt;ffffffff9968fd1e&gt;] local_pci_probe+0x3e/0x90
    [&lt;ffffffff996918a3&gt;] pci_device_probe+0xc3/0x230
    [&lt;ffffffff99805872&gt;] really_probe+0xe2/0x480
    [&lt;ffffffff99805c98&gt;] __driver_probe_device+0x78/0x160
    [&lt;ffffffff99805daf&gt;] driver_probe_device+0x1f/0x90
    [&lt;ffffffff9980601e&gt;] __driver_attach+0xce/0x1c0
    [&lt;ffffffff99803170&gt;] bus_for_each_dev+0x70/0xc0
    [&lt;ffffffff99804822&gt;] bus_add_driver+0x112/0x210
    [&lt;ffffffff99807245&gt;] driver_register+0x55/0x100
    [&lt;ffffffff990012d1&gt;] 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): [&lt;ffffffc0812416f8&gt;] _raw_spin_unlock_irqrestore+0x70/0xb0
    hardirqs last disabled at (40): [&lt;ffffffc08122d208&gt;] el1_dbg+0x28/0x90
    softirqs last  enabled at (36): [&lt;ffffffc080017dec&gt;] kernel_neon_begin+0x8c/0xf0
    softirqs last disabled at (34): [&lt;ffffffc080017dc0&gt;] 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 &lt;samsun1006219@gmail.com&gt;Reported by: xingwei lee &lt;xrivendell7@gmail.com&gt;</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 &apos;efi_capsule_open&apos;:
drivers/firmware/efi/capsule-loader.c:295:24: error: allocation of insufficient size &apos;4&apos; for type &apos;phys_addr_t&apos; {aka &apos;long long unsigned int&apos;} with size &apos;8&apos; [-Werror=alloc-size]
  295 |         cap_info-&gt;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 (&quot;vt: fix memory overlapping when deleting chars in the
buffer&quot;). 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&apos;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&apos;t call memtype_free() or would call
it with the wrong range, possibly leaking memory.

To fix that, let&apos;s update follow_phys() to refuse returning anon folios,
and fallback to using the stored PFN inside vma-&gt;vm_pgoff for COW mappings
if we run into that.

We will now properly handle untrack_pfn() with COW mappings, where we
don&apos;t need the cachemode.  We&apos;ll have to fail fork()-&gt;track_pfn_copy() if
the first page was replaced by an anon folio, though: we&apos;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():

&lt;--- C reproducer ---&gt;
 #include &lt;stdio.h&gt;
 #include &lt;sys/mman.h&gt;
 #include &lt;unistd.h&gt;
 #include &lt;liburing.h&gt;

 int main(void)
 {
         struct io_uring_params p = {};
         int ring_fd;
         size_t size;
         char *map;

         ring_fd = io_uring_setup(1, &amp;p);
         if (ring_fd &lt; 0) {
                 perror(&quot;io_uring_setup&quot;);
                 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(&quot;mmap&quot;);
                 return 1;
         }

         /* We have at least one page. Let&apos;s COW it. */
         *map = 0;
         pause();
         return 0;
 }
&lt;--- C reproducer ---&gt;

On a system with 16 GiB RAM and swap configured:
 # ./iouring &amp;
 # 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]  &lt;TASK&gt;
[  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-&gt;mode_config.mutex

The modes[] array contains pointers to modes on the connectors&apos;
mode lists, which are protected by dev-&gt;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&apos;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&apos;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&apos;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&apos;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-&gt;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(&amp;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 &quot;pctldev&quot; struct is allocated in devm_pinctrl_register_and_init().
It&apos;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>